<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="dc.language" scheme="rfc1766" content="en-us" />
<!-- Licensed Materials Property of IBM                      -->
<!-- US Government Users Restricted Rights                   -->
<!-- Use, duplication or disclosure restricted by            -->
<!-- GSA ADP Schedule Contract with IBM Corp.                -->
<meta name="dc.date" scheme="iso8601" content="2013-04-02" />
<meta name="copyright" content="&copy; Copyright IBM Corporation 2002, 2012" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow"/>
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="keywords" content="IClassifyBy migrating_def.dita, summary of changes to this document, changes to this document, summary of" />
<meta name="keywords" content="releases supported for migration, migration paths supported, paths supported, migration, direct migration, installation steps, migration steps" />
<meta name="keywords" content="steps for migration, migration health checks, health checks, checks, migration health, Enhanced PSP Tool, EPSPT, FIXCAT, REPORT MISSINGFIX" />
<meta name="keywords" content="IBM z/OS Management Facility, Management Facility, IBM z/OS, z/OS Management Facility, IBM, z/OSMF, none, elements and features with" />
<meta name="keywords" content="migration actions, Alternate Library for REXX, no migration actions for, BDT, BDT File-to-File, BDT SNA NJE, BookManager BUILD, BookManager READ, CIM" />
<meta name="keywords" content="Communications Server Security Level 3, EREP, ESCON Director Support, FFST, GDDM, GDDM-PGF, GDDM-REXX, HCD, HCM, HLASM, HLASM Toolkit, IBM HTTP Server" />
<meta name="keywords" content="ICKDSF, Integrated Security Services, Metal C Runtime Library, MICR/OCR, NFS, Run-Time Library Extensions, TIOC, z/OS IBM TDS, z/OS Security Level 3" />
<meta name="keywords" content="3270 PC File Transfer Program, general, for everyone, before installing, general migration actions, everyone, migration actions for" />
<meta name="keywords" content="preinstallation migration actions, reviewing, PSP bucket, upgrade IDs, for PSP buckets, URL, Internet address, web address, maintenance" />
<meta name="keywords" content="coexistence and fallback, zSoftware Migfration Capacity Planning Aid (zSoftCap), zSoftCap, capacity evaluation with zSoftCap" />
<meta name="keywords" content="CPU evaluation with zSoftCap, evaluation with zSoftCap, storage, for zSoftCap, withdrawal, DCE, Distributed Computing Environment" />
<meta name="keywords" content="Products depending on DCE technologies, for redbooks, Redbooks, z/OS root size, root size, z/OS, DASD for z/OS root, XCF groups" />
<meta name="keywords" content="Managed System Infrastructure for Setup (msys for Setup), Windows clients, support for, before first IPL, first IPL, migration actions before, IPL" />
<meta name="keywords" content="migration actions before first, pre-IPL migration actions, IPCS, setting up, used by IPCS, parmlib, SYS1.PARMLIB, using shipped members of, proclib" />
<meta name="keywords" content="SYS1.PROCLIB, /etc directory, migrating files in, /var directory, messages, updating automation for changed, examining, user modifications" />
<meta name="keywords" content="modifications, user, usermods, SVC routines, migrating, exit routines, user exits, ISV products, reconnecting, for ISVs, subsystems, procedures" />
<meta name="keywords" content="updating operational, defining new profiles, FACILITY class, RACF, verifying limits, virtual storage, setting virtual limits" />
<meta name="keywords" content="determining virtual storage with, MEMLIMIT parameter, for flashes, backing, backing virtual, updating, deleted data sets and paths" />
<meta name="keywords" content="removed data sets and paths, deleted, data sets, paths, new data sets, new, PDSE sharing restrictions, sharing restrictions, PDSE, address spaces" />
<meta name="keywords" content="hardware migration actions, hardware, compatibility changes, zEC12 server, migrating to, software support features, server, zEC12, migrating to zEC12" />
<meta name="keywords" content="processors, z196 server, zEnterprise, migrating to z196, z196, z114 server, migrating to z114, z114, SMP/E REPORT MISSINGFIX, Fix Category, HOLDDATA" />
<meta name="keywords" content="z10 server, z10, migrating to z10, software support of z10, features, software support of servers, z10 requirements, coexistence" />
<meta name="keywords" content="coexistence requirements, for Enhanced PSP Tool, ARCH(8) compiler option, TUNE(8) compiler option, HiperDispatch, Capacity Provisioning" />
<meta name="keywords" content="large page support, InfiniBand, Parallel Sysplex InfiniBand, PSIFB (Parallel Sysplex InfiniBand), z9 server, z9, migrating to z9" />
<meta name="keywords" content="software support of z9, z9 requirements, z990 server, z990, migrating to z990, z890 server, z890, migrating to z890, Compatibility Support feature" />
<meta name="keywords" content="z/OS V1R4 z990, software support of z990, z990 and z890, Exploitation Support feature, Cryptographic CP Assist Support, HMC microcode, upgrading" />
<meta name="keywords" content="for Resource Link, z990 coexistence requirements, z990 requirements, z890 coexistence requirements, z890 requirements" />
<meta name="keywords" content="CFCC (coupling facility control code), z990 CFCC requirements, migrating to z990 or z890, SMF records, CSFIPCSP new member for ICSF" />
<meta name="keywords" content="unsupported devices, removing, removing unsupported, devices, attaching new, relieving virtual storage constraint with, link pack area (LPA)" />
<meta name="keywords" content="LPA (link pack area), coupling facility control code (CFCC) levels, levels, CFRM policy, for CFSizer tool, for CFCC levels and processors" />
<meta name="keywords" content="Server Time Protocol (STP) feature, STP (Server Time Protocol) feature, sysplex, sysplex migration actions, Parallel Sysplex migration actions" />
<meta name="keywords" content="after first IPL, migration actions after, migration actions after first, post-IPL migration actions, BCP, BCP migration actions, dump data sets" />
<meta name="keywords" content="stand-alone, stand-alone dump data sets, IEASYSxx, WARNUND, DASD, Predictive Failure Analysis (PFA), storage requirements, DASD requirements, BCPii" />
<meta name="keywords" content="capacity provisioning, INIT, DEFAULT, HARDCOPY and CONSOLE keyword statements require blank delimiter., CONSOL<var class='pv'>xx</var>, CPCC" />
<meta name="keywords" content="Capacity Provisioning Control Center, PGSER, EEPLEVENTSPECIFICINFO, RTLS, CSVRTLS, IPL text, creating, stand-alone dump, reassembling, dump" />
<meta name="keywords" content="reassembling stand-alone, one-step JCL, one-stage JCL, &lt;bogus index entry>, ESQA, memory pool, Flash Express, discontinue use, MTFTPS" />
<meta name="keywords" content="problem documentation upload utility (PDUU), default change, CLEANUP_TIMEOUT, CLEANUP_TIMEOUT parameter of the automatic restart management (ARM)" />
<meta name="keywords" content="default changes, XCF/XES, restart, library lookaside (LLA), automation, CSVLLAxx member, OPERLOG EMCS console name change, CMDS ABEND command" />
<meta name="keywords" content="CMDS FORCE command, CON=, HIPERDISPATCH=YES, default, IEAOPTxx keyword, COMMNDxx, Runtime Diagnostics, start, HZR address space, problem management" />
<meta name="keywords" content="IRARASD macro, recompile module which includes, SYSEVENT REQFASD, work area, console commands and problem determination" />
<meta name="keywords" content="problem determination and console commands, CONSOLxx, ALLOWCMD(Y) keyword, SMF messages, CTIGRSxx, IFASMFDL, IFASMFDP, directory setting" />
<meta name="keywords" content="PFA (Predictive Failure Analysis), AIRSHREP.sh, DIAGxx parmlib, parmlib DIAGxx, LCCA, PCCA, CUNIDHC2, EWLM transaction class name (ETC), ETC" />
<meta name="keywords" content="EWLM transaction class name, REUSASID, Auto-reply for WTORs, LOGRECSUMMARY statement value in CEAPRMxx, CEAPRMxx, Provisioning Manager" />
<meta name="keywords" content="CIM Client for Java Version 2, GRS, AUTHQLVL parameter, GRSCNFxx parmlib member, qnames, Runtime Diagnostics and PFA, PFA, AMBLIST command" />
<meta name="keywords" content="Hardware Instrumentation Services (HIS), HIS (Hardware Instrumentation Services), MVS_Binder, Communications Server" />
<meta name="keywords" content="Communications Server migration actions, Before installing, FTP daemon console messages, FTP, User ID for the resolver, define" />
<meta name="keywords" content="QDIO inbound workload queueing for EE traffic, workload queueing function for EE traffic" />
<meta name="keywords" content="Enterprise Extender (EE) traffic and QDIO inbound workload queueing, ancillary input queue (AIQ), IKE daemon, FIPS mode, ICSF, CSFPDVK and CSFPDMK" />
<meta name="keywords" content="BIND 9.2.0, DNS and BIND 9.2.0, Intrusion Detection Services and traffic monitoring, traffic monitoring, attack detection, scan detection, FTCHKPWD" />
<meta name="keywords" content="FTP user exit routine FTCHKPWD, FTCHKPWD exit routine, additional parameter, password or password phrase, VIPARANGE processing, understand" />
<meta name="keywords" content="IP filter policy, RFC 4301, IpFilterPolicy statement, filtering, IP policy, fragments, SNMP sysObjectID MIB object, sysObjectID MIB object, SNMP" />
<meta name="keywords" content="MIB object, SNMP sysObjectID, OSNMPD.DATA file, SNMP sysObjectID MIB object in, resolver UDP request timeout interval duration" />
<meta name="keywords" content="UDP request timeout interval duration, timeout interval duration, struct addrinfo, getaddrinfo(), RFC 5014, resolver and addrinfo storage" />
<meta name="keywords" content="addrinfo storage, multi-thread tasks, syslogd configuration, z/OS UNIX file destinations, IVTCSM ASSIGN_BUFFER requests, CSM buffer, reason code 26" />
<meta name="keywords" content="CSA shortage, VTAMSG2, TCPIPDS1 and ISTITDS1 specification from dump commands, removal, VIPARANGE definitions, review, TN3270E Telnet server messages" />
<meta name="keywords" content="resolver monitoring of name server responsiveness, name server responsiveness, resolver monitoring of, IP validation checks, security key exchanges" />
<meta name="keywords" content="defining key exchange policy rules for a dynamic VPN, key exchange policy rules for a dynamic VPN, policy rules for a dynamic VPN" />
<meta name="keywords" content="defining key exchange, dynamic VPN, defining key exchange policy rules, Netstat message catalogs and timestamps, message catalogs" />
<meta name="keywords" content="timestamps of Netstat message catalogs, VTAM internal trace, TRACE command, VTAM start list, Enterprise Extender connection health" />
<meta name="keywords" content="MULTPATH=TCPVALUE start option, TCP/IP preference values, IPv6 router advertisement messages, router advertisement messages, Cryptographic Services" />
<meta name="keywords" content="ICSF migration actions, OCSF migration actions, Cryptographic Services migration actions, ICSF migration action" />
<meta name="keywords" content="ensuring that the CSFPUTIL utility is not used to initialize a PKDS, Modify ICSF startup procedure, ICSF startup procedure, modifying" />
<meta name="keywords" content="for ABENDDC2-16 in CSFKSTDC, OCSF directory migration, OCSF profiles, PKCS #11 tokens, PKCS #11 token certificate chains" />
<meta name="keywords" content="SSL V3 and TLS session renegotiation, System SSL, enabling SSL V3 and TLS session renegotiation" />
<meta name="keywords" content="enabling SSL V3 and TLS session renegotiation for System SSL, System SSL migration action" />
<meta name="keywords" content="ensuring that all RACF user IDs can access the CSFIQA resource, ICSF master keys, master keys, PKI Services, daily maintenance task" />
<meta name="keywords" content="daily maintenance task for PKI Services, maintenance task for PKI Services, DFSMS, DFSMS migration actions, SMS control data sets, control data sets" />
<meta name="keywords" content="migrating SMS, data integrity of SMS control data sets, integrity of SMS control data sets, source control data set (SCDS), ensuring integrity of" />
<meta name="keywords" content="SCDS (source control data set), ACDS (active control data set), active control data set (ACDS), COMMDS (common communications data set)" />
<meta name="keywords" content="common communications data set (COMMDS), migration action for, removal of NOIMBED and NOREPLICAT from output, LISTCAT, modify to support 31-bit UCB" />
<meta name="keywords" content="IGGPRE00, IGGPOST0, DADSM, IMBED attribute for VSAM data sets, removal of, REPLICATE attribute for VSAM data sets" />
<meta name="keywords" content="KEYRANGE attribute for VSAM data sets, VSAM IMBED, REPLICATE, and KEYRANGE support removed, backward-compatible no longer supported by DFSMSrmm" />
<meta name="keywords" content="CIM provider, CIM providers and classes changed for DFSMSrmm, replace CIM providers and CIM classes, DFSMSrmm, IGGCATxx" />
<meta name="keywords" content="dynamic link libraries with Language Environment, DLLs (dynamic link libraries) with Language Environment, 3800 Printing Subsystem, preparing to use" />
<meta name="keywords" content="3900 Printing Subsystem, SYS1.IMAGELIB, core image of DFSMSdss Stand-Alone Services, building, Stand-Alone Services, building core image of DFSMSdss" />
<meta name="keywords" content="DFSMSdss, IEEVARYD, update operator procedures for, DADSM pre- and post-processing, IEBCOPY update, modify application programs for, EAV enhancements" />
<meta name="keywords" content="BSAM, QSAM, and BPAM, modify for new DCBE macro option, IFG019LA, IFG019VM, IFG019FV, IFG019FS, IFG055FE, NSLOHDRI, NSLEHDRI, NSLOHDRO, NSLEHDRO" />
<meta name="keywords" content="NSLETRLI, NSLETRLO, NSLCTRLO, IEFXVNSL, NSLREPOS, IFG0193C, IFG0553C, IFG0EX0B, IGXMSGEX, IFG0199I, IFG0193G, ADRUIXIT, ADRUFO block, EIOP03, EIOP06" />
<meta name="keywords" content="DUMP, COPYDUMP, RESTORE, at startup, PDA trace, DFSMShsm, data set recovery, fast replication, using, FlashCopy, FRRECOV, DATASETRECOVERY" />
<meta name="keywords" content="SETSYS FASTREPLICATION, DATASETRECOVERY parameter, tuning, ARC1809I, patch disabling unwanted ARC1809I messages (DFSMShsm), VOLUMEPAIRMESSAGES" />
<meta name="keywords" content="ARC0036I (E), ARC0503I (E), ARC0704I (E), ARC0036, changed type, ARC0503, ARC0704, DFSMShsm: Removal of the patch preventing the SMS MVT chain rebuild" />
<meta name="keywords" content="Removal of the patch preventing the SMS MVT chain rebuild (DFSMShsm), patch preventing the SMS MVT chain rebuild (DFSMShsm)" />
<meta name="keywords" content="preventing the SMS MVT chain rebuild (DFSMShsm), removal of patch, SMS MVT chain rebuild (DFSMShsm), removal of patch preventing" />
<meta name="keywords" content="MVT (SMS) chain rebuild (DFSMShsm), chain rebuild (DFSMShsm), removal of patch preventing SMS MVT, rebuild of chain (DFSMShsm), Multicluster CDS" />
<meta name="keywords" content="DFSMSdss cross memory interface, SETSYS DSSXMMODE, security system, ARC1820I, DFSMShsm QUERY, QUERY command, output changes, command output" />
<meta name="keywords" content="DFSMShsm LIST, LIST command, ARCBDEXT, DFSMS macros, 64-bit mode, AR mode, migration job for DFSMSdfp OAM., CBRSMR1D" />
<meta name="keywords" content="OAM configuration database migration job (CBRSMR1D), DFSMSdfp OAM., OAM DB2 BIND jobs, BIND jobs, OAM DB2, DB2 BIND jobs, OAM, zFS file system" />
<meta name="keywords" content="DFSMSdfp, Catalog Search Interface (CSI), CSI (Catalog Search Interface), resource contention, ARCCAT, CDS backup, when starting CDS backup, ARRCAT" />
<meta name="keywords" content="DFSORT, DFSORT migration actions, DFSORT MOWRK, MOWRK, DFSORT dynamic allocation, DYNALOC/DYNALLOC, Distributed File Service" />
<meta name="keywords" content="Distributed File Service migration actions, zFS storage requirements, IOEFSPRM, zfsspace utility, .bak file system, zFS cloning support" />
<meta name="keywords" content="zFS multi-file system aggregates, zFS compatibility mode aggregates, zFS, sysplex=filesys, shared file system, zFS virtual storage verification" />
<meta name="keywords" content="DFS client (DFSCM), DCE/DFS, Infoprint Server, Infoprint Server migration actions, installing, Increasing space for Printer Inventory" />
<meta name="keywords" content="Removing Version 2 Printer Inventory, Upgrade Java for IPP Server, printer inventory, region size change, IEFUSI, Upgrade XML for Infoprint Central" />
<meta name="keywords" content="IP PrintWay migration from basic mode to extended mode, basic mode to extended mode, IP PrintWay migration from, extended mode" />
<meta name="keywords" content="IP PrintWay migration from basic mode to, aopsetup, running, Removing Version 1 Printer Inventory, ISPF, ISPF migration actions, JES2" />
<meta name="keywords" content="JES2 migration actions, JES, z11 mode, JES3, JES3 migration actions, JES3 DLOG, DLOG, *S main, FLUSH, Automatic flush, DATLOREC, DATINPTR (IATYDAT)" />
<meta name="keywords" content="IAT3100, Messages, Language Environment, Language Environment migration actions, runtime options, Language Environment changes to, options" />
<meta name="keywords" content="Language Environment changes to runtime, Language Environment options, CICS system definition file for Language Environment" />
<meta name="keywords" content="CSD (CICS system definition) file for Language Environment, Language Environment load modules in, for Language Environment options, D CEE" />
<meta name="keywords" content="runtime options report, CEEPRMxx parmlib member, runtime options in CEEPRMxx parmlib member, CLER runtime options report, conversion table removal" />
<meta name="keywords" content="Unicode Services, Library Server, Library Server migration actions, notes files, RMF, RMF migration actions, ERB812I, ERB813I, Monitor III version" />
<meta name="keywords" content="using correct, SMF 72.5 data collection, IN-READY QUEUE, SDSF, SDSF migration actions, ISFPARMS, WebSphere MQ with SDSF" />
<meta name="keywords" content="sysplex-wide data on SDSF panels, OPERLOG panel, devices on the SDSF PUN panel, devices on the SDSF RDR panel, SDSF custom properties" />
<meta name="keywords" content="initiators on the SDSF INIT panel, WLM-managed initiators on the SDSF INIT panel, devices on the SDSF PR panel, ISF770W, SDSF message ISF770W" />
<meta name="keywords" content="Security Server, Security Server migration actions, RACF migration actions, distributed identify filter, identity propagation" />
<meta name="keywords" content="normalization of RACF user names, class name conflicts, duplicate class names, router table, class descriptor table (CDT) names" />
<meta name="keywords" content="CDT (class descriptor table) names, database templates, updating RACF, RACF database templates, IRRMIN00 utility, REKEY, RACDCERT GENCERT" />
<meta name="keywords" content="RACDCERT GENCERT and REKEY defaults, RACDCERT REKEY, SMP/E, after installing but before using, SMP/E migration actions, authorize commands, SAF checks" />
<meta name="keywords" content="SMP/E functions, security, TSO/E, TSO/E migration actions, &amp;lt;ogus index entry>, AVGREC option of TSO/E, C/C++, XL C/C++" />
<meta name="keywords" content="XL C/C++ migration actions, IPA option changes, z/OS UNIX, z/OS UNIX migration actions, /usr/sbin/mount invocations, /usr/sbin/unmount invocations" />
<meta name="keywords" content="BPX1EXM/BPX4EXM callable service, support added, tsocmd shell command, support deleted from AF_UNIX, MAXSOCKETS statement, MAXSOCKETS" />
<meta name="keywords" content="remove values from AF_UNIX, migration action, Process Manager, Connection Manager, z/OS UNIX System Services Connection Scaling, HFS to zFS" />
<meta name="keywords" content="migrating file system from, migrating from HFS to, sysplex root from HFS to zFS, symbolic links for cron, mail, and uucp utilities" />
<meta name="keywords" content="invalid REXX variables, skulker shell command, BPX.UNIQUE.USER profile, BPX.DEFAULT.USER profile replaced by BPX.UNIQUE.USER" />
<title>Migration </title>
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
</head>
<body role="main">
<a id="Top_Of_Page"></a><h1>z/OS</h1>
<h1>Migration </h1><span class="version">Version 1</span> 
<span class="release">Release 13</span>
<br />
<span class="ibmdocnum">GA22-7499-21</span><br /><a id="idx1"></a>
<div id="toc">
<h1>Contents</h1>
<div class="head1"><a id="ToC_1" href="#abstract" class="toclink">Abstract for Migration</a></div>
<div class="head1"><a id="ToC_2" href="#soasoc" class="toclink">Summary of changes</a></div>
<div class="head2"><a id="ToC_3" href="#wq1" class="toclink">Changes made in z/OS Version 1 Release 13 as updated September 2012</a></div>
<div class="head2"><a id="ToC_4" href="#wq4" class="toclink">Changes made in z/OS Version 1 Release 13 as updated April 2012</a></div>
<div class="head2"><a id="ToC_5" href="#wq7" class="toclink">Changes made in z/OS Version 1 Release 13</a></div>
<div class="head1"><a id="ToC_6" href="#chintro" class="toclink">Introduction</a></div>
<div class="head2"><a id="ToC_7" href="#typmste" class="toclink">Typical migration steps</a></div>
<div class="head2"><a id="ToC_8" href="#mighlch" class="toclink">Using IBM Health Checker for z/OS for migration checking</a></div>
<div class="head2"><a id="ToC_9" href="#eholdda" class="toclink">EPSPT replaced by FIXCAT and REPORT MISSINGFIX</a></div>
<div class="head2"><a id="ToC_10" href="#zosmfloc" class="toclink">z/OS Management Facility</a></div>
<div class="head2"><a id="ToC_11" href="#eafwoma" class="toclink">Elements and features that do not have migration actions</a></div>
<div class="head1"><a id="ToC_12" href="#at1ever" class="toclink">Migration actions for everyone</a></div>
<div class="head2"><a id="ToC_13" href="#wq14" class="toclink">Migration actions for everyone before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_14" href="#pspbuck" class="toclink">Review PSP buckets</a></div>
<div class="head3"><a id="ToC_15" href="#coxptfs" class="toclink">Install coexistence and fallback PTFs</a></div>
<div class="head3"><a id="ToC_16" href="#at3sofc" class="toclink">Use zSoftCap to identify the effect of capacity changes</a></div>
<div class="head3"><a id="ToC_17" href="#dcegone" class="toclink">Stop using Computing Environment (DCE) and DCE Security Server</a></div>
<div class="head3"><a id="ToC_18" href="#zrodasd" class="toclink">Add or change volumes to keep your z/OS root file system in a single data set</a></div>
<div class="head3"><a id="ToC_19" href="#vxcfgps" class="toclink">Verify that you have enough XCF groups in your CDS and enough XCF members in your XCF groups</a></div>
<div class="head3"><a id="ToC_20" href="#msysset" class="toclink">Stop using Managed System Infrastructure for Setup (msys for Setup) element</a></div>
<div class="head3"><a id="ToC_21" href="#at3uw9c" class="toclink">Upgrade Windows 2000, 98, 95, and NT clients</a></div>
<div class="head2"><a id="ToC_22" href="#wq30" class="toclink">Migration actions for everyone before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_23" href="#at3gena" class="toclink">Set up an IPCS environment</a></div>
<div class="head3"><a id="ToC_24" href="#at3genb" class="toclink">Use IBM-supplied parmlib and proclib members</a></div>
<div class="head3"><a id="ToC_25" href="#at3gend" class="toclink">Migrate /etc and /var system control files</a></div>
<div class="head3"><a id="ToC_26" href="#automsg" class="toclink">Update automation and procedures for changed and deleted messages</a></div>
<div class="head3"><a id="ToC_27" href="#at3geng" class="toclink">Rework and install user modifications</a></div>
<div class="head3"><a id="ToC_28" href="#at3genh" class="toclink">Reconnect non-IBM products</a></div>
<div class="head3"><a id="ToC_29" href="#at3geni" class="toclink">Reconnect subsystems</a></div>
<div class="head3"><a id="ToC_30" href="#at3genj" class="toclink">Update operational and other procedures</a></div>
<div class="head3"><a id="ToC_31" href="#at3limi" class="toclink">Verify that virtual storage limits are set properly</a></div>
<div class="head3"><a id="ToC_32" href="#at3back" class="toclink">Back virtual storage with sufficient real and auxiliary storage</a></div>
<div class="head3"><a id="ToC_33" href="#uplochk" class="toclink">Update your check customization for modified IBM Health Checker for z/OS checks</a></div>
<div class="head3"><a id="ToC_34" href="#at3gene" class="toclink">Remove deleted data sets, paths, and references</a></div>
<div class="head3"><a id="ToC_35" href="#at3genf" class="toclink">Add references to new data sets and paths</a></div>
<div class="head3"><a id="ToC_36" href="#af32m" class="toclink">Accommodate new address spaces</a></div>
<div class="head2"><a id="ToC_37" href="#wq71" class="toclink">Migration actions for everyone after the first IPL of z/OS V1R13</a></div>
<div class="head1"><a id="ToC_38" href="#au1hard" class="toclink">Hardware migration actions</a></div>
<div class="head2"><a id="ToC_39" href="#znext2" class="toclink">Migrate to an IBM zEnterprise zEC12 server</a></div>
<div class="head3"><a id="ToC_40" href="#znextrec2" class="toclink">General recommendations and considerations for a zEC12 server</a></div>
<div class="head3"><a id="ToC_41" href="#znextres2" class="toclink">Restrictions for a zEC12 server</a></div>
<div class="head3"><a id="ToC_42" href="#znextbef2" class="toclink">Actions you can take before you order a zEC12 server</a></div>
<div class="head3"><a id="ToC_43" href="#znextaft2" class="toclink">Migration and exploitation considerations for zEC12 server functions</a></div>
<div class="head3"><a id="ToC_44" href="#z2012hw" class="toclink">Accommodate functions for the zEC12 server to be discontinued on future servers</a></div>
<div class="head2"><a id="ToC_45" href="#mignext" class="toclink">Migrate to an IBM zEnterprise z196 or z114 server</a></div>
<div class="head3"><a id="ToC_46" href="#znextrec" class="toclink">General recommendations and considerations for z196 and z114 servers</a></div>
<div class="head3"><a id="ToC_47" href="#znextres" class="toclink">Restrictions for a z196 or z114 server</a></div>
<div class="head3"><a id="ToC_48" href="#znextbef" class="toclink">Actions you can take before you order a z196 and z114 server</a></div>
<div class="head3"><a id="ToC_49" href="#znextaft" class="toclink">Actions you can take after you order a z196 and z114 server</a></div>
<div class="head3"><a id="ToC_50" href="#znxtrmss" class="toclink">Recommended migration steps for z196 and z114 servers</a></div>
<div class="head3"><a id="ToC_51" href="#znextexp" class="toclink">Migration and exploitation considerations for z196 and z114 server functions</a></div>
<div class="head3"><a id="ToC_52" href="#znextsod" class="toclink">Accommodate functions for the z196 and z114 servers to be discontinued on future servers</a></div>
<div class="head2"><a id="ToC_53" href="#migrz10" class="toclink">Migrate to a System z10 server</a></div>
<div class="head3"><a id="ToC_54" href="#wq117" class="toclink">General recommendations and considerations for a System z10 server</a></div>
<div class="head3"><a id="ToC_55" href="#wq119" class="toclink">Restrictions for a System z10 server</a></div>
<div class="head3"><a id="ToC_56" href="#wq121" class="toclink">Actions you can take before you order a System z10 server</a></div>
<div class="head3"><a id="ToC_57" href="#wq123" class="toclink">Actions you can take after you order a System z10 server</a></div>
<div class="head3"><a id="ToC_58" href="#z10rmss" class="toclink">Recommended migration steps for a System z10 server</a></div>
<div class="head3"><a id="ToC_59" href="#wq130" class="toclink">Migration and exploitation considerations for System z10 functions</a></div>
<div class="head2"><a id="ToC_60" href="#mtodanu" class="toclink">Migrate to a System z9 server</a></div>
<div class="head3"><a id="ToC_61" href="#wq139" class="toclink">General recommendations and considerations for a System z9 server</a></div>
<div class="head3"><a id="ToC_62" href="#restric" class="toclink">Restrictions for a System z9 server</a></div>
<div class="head3"><a id="ToC_63" href="#miganow" class="toclink">Actions you can take before you order a System z9 server</a></div>
<div class="head3"><a id="ToC_64" href="#wq143" class="toclink">Actions you can take after you order a System z9 server</a></div>
<div class="head3"><a id="ToC_65" href="#recscen" class="toclink">Recommended migration steps for a System z9 server</a></div>
<div class="head3"><a id="ToC_66" href="#futhard" class="toclink">Accommodate functions for the System z9 platform to be discontinued on future servers</a></div>
<div class="head2"><a id="ToC_67" href="#mtoz990" class="toclink">Migrate to a z990 or z890 server</a></div>
<div class="head3"><a id="ToC_68" href="#wq149" class="toclink">Actions you can take before you install a z990 or z890 server</a></div>
<div class="head3"><a id="ToC_69" href="#wq165" class="toclink">Actions you can take when you order a z990 or z890 server</a></div>
<div class="head3"><a id="ToC_70" href="#aaicore" class="toclink">Actions you can take after you install z/OS for a z990 or z890 server</a></div>
<div class="head3"><a id="ToC_71" href="#wq167" class="toclink">Actions you might need to take once you are using a z990 or z890 server</a></div>
<div class="head2"><a id="ToC_72" href="#at3ruio" class="toclink">Replace unsupported devices</a></div>
<div class="head2"><a id="ToC_73" href="#au3ndv" class="toclink">Provide for new device installations</a></div>
<div class="head2"><a id="ToC_74" href="#au3cpfl" class="toclink">Update your CFRM policy with coupling facility structure size changes</a></div>
<div class="head2"><a id="ToC_75" href="#sttostp" class="toclink">Migrate from a Sysplex Timer to STP</a></div>
<div class="head2"><a id="ToC_76" href="#phoicb4" class="toclink">Migrate from ICB-4 to Infiniband coupling links</a></div>
<div class="head1"><a id="ToC_77" href="#av1pars" class="toclink">Sysplex migration actions</a></div>
<div class="head2"><a id="ToC_78" href="#wq176" class="toclink">Sysplex actions related to hardware upgrades</a></div>
<div class="head2"><a id="ToC_79" href="#wq180" class="toclink">Sysplex actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_80" href="#wq185" class="toclink">Sysplex actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_81" href="#wq190" class="toclink">Sysplex actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head1"><a id="ToC_82" href="#aa1bcp" class="toclink">BCP migration actions</a></div>
<div class="head2"><a id="ToC_83" href="#wq195" class="toclink">BCP actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_84" href="#edumpds" class="toclink">Evaluate your stand-alone dump data set allocations and your IPCS processing of them</a></div>
<div class="head3"><a id="ToC_85" href="#warnund" class="toclink">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</a></div>
<div class="head3"><a id="ToC_86" href="#dasdpfa" class="toclink">Define DASD storage for Predictive Failure Analysis</a></div>
<div class="head3"><a id="ToC_87" href="#sodbcpii" class="toclink">Migrate from SNMP to z/OS BCPii for communication to the HMC or SE</a></div>
<div class="head3"><a id="ToC_88" href="#oneblank" class="toclink">Verify that at  least one blank follows all major keyword statements in CONSOLExx</a></div>
<div class="head3"><a id="ToC_89" href="#cplibpath" class="toclink">Upgrade Java support for Capacity Provisioning</a></div>
<div class="head3"><a id="ToC_90" href="#pgserpro" class="toclink">Discontinue use of PGSER to protect and unprotect the READONLY nucleus</a></div>
<div class="head3"><a id="ToC_91" href="#xesfieldlen" class="toclink">Review changes to XES Event Exit Parameter List (IXLYEEPL) field length</a></div>
<div class="head3"><a id="ToC_92" href="#remrtls" class="toclink">Track CSVRTLS services</a></div>
<div class="head2"><a id="ToC_93" href="#wq207" class="toclink">BCP actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_94" href="#aa3iplt" class="toclink">Create IPL text</a></div>
<div class="head3"><a id="ToC_95" href="#aa3sad" class="toclink">Reassemble the stand-alone dump program</a></div>
<div class="head3"><a id="ToC_96" href="#nucleus" class="toclink">Accommodate increase in nucleus size for  the z/OS V1R13 RSM Enablement Offering Web deliverable</a></div>
<div class="head3"><a id="ToC_97" href="#esqa" class="toclink">Accommodate increase in ESQA with the z/OS V1R13 RSM Enablement Offering Web deliverable</a></div>
<div class="head3"><a id="ToC_98" href="#pduu" class="toclink">Remove references to the MTFTPS utility</a></div>
<div class="head3"><a id="ToC_99" href="#oa35357" class="toclink">Change value for ARM restart processing</a></div>
<div class="head3"><a id="ToC_100" href="#dxcfmsg" class="toclink">Modify automation that references output from D XCF,SYSPLEX console commands</a></div>
<div class="head3"><a id="ToC_101" href="#llaauto" class="toclink">Update LLA for automation</a></div>
<div class="head3"><a id="ToC_102" href="#operloge" class="toclink">Accommodate OPERLOG EMCS console name change</a></div>
<div class="head3"><a id="ToC_103" href="#conparm" class="toclink">Adjust CON= system parameter to accommodate default change</a></div>
<div class="head3"><a id="ToC_104" href="#hyperz196" class="toclink">Accommodate HiperDispatch default of YES on IBM zEnterprise zEC12 and IBM zEnterprise (z196 and z114)</a></div>
<div class="head3"><a id="ToC_105" href="#commndxx" class="toclink">Start Runtime Diagnostics at system initialization</a></div>
<div class="head3"><a id="ToC_106" href="#sysevent" class="toclink">Ensure all modules of an application are compiled with the same version of the IRARASD macro</a></div>
<div class="head3"><a id="ToC_107" href="#oa34731" class="toclink">Issue commands from the system console regardless of problem determination mode</a></div>
<div class="head3"><a id="ToC_108" href="#ief37smf" class="toclink">Update automation that handles messages IEF374I and IEF376I</a></div>
<div class="head3"><a id="ToC_109" href="#ctigrsd" class="toclink">Use the new 16M default buffer size for trace options with the CTIGRSxx member</a></div>
<div class="head3"><a id="ToC_110" href="#ifasmf1" class="toclink">Specify valid user exits for the IFASMFDL and IFASMFDP programs</a></div>
<div class="head3"><a id="ToC_111" href="#ifasmf2" class="toclink">Make IFASMFDL and IFASMFDP run in an authorized environment</a></div>
<div class="head3"><a id="ToC_112" href="#pfaparm" class="toclink">Provide the <var class="pv">migrate</var> or <var class="pv">new</var> parameter when running the PFA install script</a></div>
<div class="head3"><a id="ToC_113" href="#lccapcca" class="toclink">Change default locations for LCCA or PCCA control blocks to retain 24-bit virtual storage location</a></div>
<div class="head3"><a id="ToC_114" href="#cunidhc" class="toclink">Remove reference to Unicode Services pre-built image CUNIDHC2</a></div>
<div class="head3"><a id="ToC_115" href="#etcwork" class="toclink">Remove classification rules with the ETC work qualifier</a></div>
<div class="head3"><a id="ToC_116" href="#sfmpoli" class="toclink">Update the SFM policy to control automatic termination of impaired critical members</a></div>
<div class="head3"><a id="ToC_117" href="#reusasi" class="toclink">Accommodate new REUSASID default</a></div>
<div class="head3"><a id="ToC_118" href="#autoroo" class="toclink">Review the list of WTORs in parmlib member AUTOR00</a></div>
<div class="head3"><a id="ToC_119" href="#logrecsum" class="toclink">Adjust LOGRECSUMMARY statement value in CEAPRMxx member</a></div>
<div class="head2"><a id="ToC_120" href="#wq255" class="toclink">BCP actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_121" href="#javacpm" class="toclink">Update Capacity Provisioning Manager parameters to use CIM client for Java Version 2</a></div>
<div class="head3"><a id="ToC_122" href="#grsficon" class="toclink">Migrate to GRS-managed FICON CTCs</a></div>
<div class="head3"><a id="ToC_123" href="#grsauthql" class="toclink">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize new GRS qnames</a></div>
<div class="head3"><a id="ToC_124" href="#cmdsabe" class="toclink">Examine use of the CMDS ABEND command</a></div>
<div class="head3"><a id="ToC_125" href="#rtdpfa" class="toclink">Ensure Runtime Diagnostics is installed before invoking Predictive Failure Analysis</a></div>
<div class="head3"><a id="ToC_126" href="#cpccdef" class="toclink">Carry over your existing CPCC policy</a></div>
<div class="head3"><a id="ToC_127" href="#binder1" class="toclink">Evaluate applications that parse AMBLIST command LISTLOAD or LISTIDR output</a></div>
<div class="head3"><a id="ToC_128" href="#hiscomp" class="toclink">Ensure analysis tools interacting with HIS output accommodate HIS state change events</a></div>
<div class="head3"><a id="ToC_129" href="#initlod" class="toclink">Detect program objects that have multiple INITIAL LOAD segments</a></div>
<div class="head3"><a id="ToC_130" href="#pfamax" class="toclink">Add to the maximum number of open files under z/OS UNIX Systems Services for PFA</a></div>
<div class="head1"><a id="ToC_131" href="#ad1coms" class="toclink">Communications Server migration actions</a></div>
<div class="head2"><a id="ToC_132" href="#wq277" class="toclink">Communications Server actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_133" href="#ftpdaemon" class="toclink">IP Services: Accommodate new format of FTP daemon console messages that no longer are prefixed with '+'</a></div>
<div class="head3"><a id="ToC_134" href="#defidresolve" class="toclink">IP Services: Define a user ID for the system resolver with an associated OMVS segment</a></div>
<div class="head3"><a id="ToC_135" href="#meestorg" class="toclink">IP Services: Ensure storage availability for ancillary input queue for Enterprise Extender traffic</a></div>
<div class="head3"><a id="ToC_136" href="#ipfips" class="toclink">IP Services: Permit IKE daemon running in FIPS mode to use additional ICSF services</a></div>
<div class="head3"><a id="ToC_137" href="#sodbind" class="toclink">IP Services: Migrate from BIND 9.2.0</a></div>
<div class="head3"><a id="ToC_138" href="#commsids" class="toclink">IP Services: Understand and prepare for expanded Intrusion Detection Services</a></div>
<div class="head3"><a id="ToC_139" href="#ftchkpwd" class="toclink">IP Services: Ensure that the FTP user exit routine FTCHKPWD tolerates an additional parameter</a></div>
<div class="head3"><a id="ToC_140" href="#portrnge" class="toclink">IP Services: Understand change in VIPARANGE security verification processing</a></div>
<div class="head3"><a id="ToC_141" href="#ipfrags" class="toclink">IP Services: Update IP filter policy to filter IP fragments correctly for RFC 4301 compliance</a></div>
<div class="head3"><a id="ToC_142" href="#snmpsys" class="toclink">IP Services: Remove customization of SNMP sysObjectID MIB object in OSNMPD.DATA file</a></div>
<div class="head3"><a id="ToC_143" href="#ressolv" class="toclink">IP Services: Restore resolver UDP request timeout interval duration</a></div>
<div class="head3"><a id="ToC_144" href="#addrinf" class="toclink">IP Services: Ensure applications tolerate a larger addrinfo structure</a></div>
<div class="head3"><a id="ToC_145" href="#restask" class="toclink">IP Services: Release addrinfo storage after resolver thread task terminates</a></div>
<div class="head3"><a id="ToC_146" href="#syslogup" class="toclink">IP Services: Update syslogd configuration for archiving rules with shared z/OS UNIX file destinations</a></div>
<div class="head3"><a id="ToC_147" href="#asgnbuf" class="toclink">SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests do not exceed 500 images for a single CSM buffer</a></div>
<div class="head3"><a id="ToC_148" href="#vtamsgt" class="toclink">SNA Services: Ensure VTAMSG2 in not used in your VTAMLST definitions</a></div>
<div class="head2"><a id="ToC_149" href="#wq305" class="toclink">Communications Server actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_150" href="#tcpip" class="toclink">IP and SNA Services: Remove TCPIPDS1 and ISTITDS1 specification from dump commands</a></div>
<div class="head3"><a id="ToC_151" href="#viparange" class="toclink">IP Services: Review VIPARANGE definitions</a></div>
<div class="head3"><a id="ToC_152" href="#tn3720e" class="toclink">IP Services: Update automation that keys on TN3270E Telnet server messages</a></div>
<div class="head3"><a id="ToC_153" href="#telsrvr" class="toclink">IP Services: Ensure the TN3270E Telnet server can end automatically when an OMVS shutdown command is issued</a></div>
<div class="head3"><a id="ToC_154" href="#disreso" class="toclink">IP Services: Disable resolver monitoring of name server responsiveness</a></div>
<div class="head3"><a id="ToC_155" href="#dynavpm" class="toclink">IP Services: Disable IP validation checks when defining key exchange policy rules for a dynamic VPN</a></div>
<div class="head3"><a id="ToC_156" href="#modnets" class="toclink">IP Services: Update modified Netstat message catalogs to include timestamp</a></div>
<div class="head3"><a id="ToC_157" href="#upcsetc" class="toclink">IP Services: Update /etc configuration files</a></div>
<div class="head3"><a id="ToC_158" href="#vitrelocate" class="toclink">SNA Services: Adjust to the relocation of the VTAM internal trace table</a></div>
<div class="head3"><a id="ToC_159" href="#eeconnh" class="toclink">SNA Services: Disable Enterprise Extender connection health verification</a></div>
<div class="head3"><a id="ToC_160" href="#multpth" class="toclink">SNA Services: Code MULTPATH start option when using multipath</a></div>
<div class="head2"><a id="ToC_161" href="#wq327" class="toclink">Communications Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_162" href="#ipvpref" class="toclink">IP Services: Ensure that preference values associated with IPv6 router advertisement routes are as expected</a></div>
<div class="head1"><a id="ToC_163" href="#ae1cryp" class="toclink">Cryptographic Services migration actions</a></div>
<div class="head2"><a id="ToC_164" href="#wq330" class="toclink">Cryptographic Services actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_165" href="#icsfpkc" class="toclink">ICSF: Ensure PKCS #11 applications call C_Finalize() prior to calling dlclose()</a></div>
<div class="head2"><a id="ToC_166" href="#wq333" class="toclink">Cryptographic Services actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_167" href="#icsfcsfpu" class="toclink">ICSF: Ensure the CSFPUTIL utility is not used to initialize a PKDS</a></div>
<div class="head3"><a id="ToC_168" href="#modstrt" class="toclink">ICSF: Modify ICSF startup procedure</a></div>
<div class="head3"><a id="ToC_169" href="#ae3ois" class="toclink">OCSF: Migrate the directory structure</a></div>
<div class="head3"><a id="ToC_170" href="#pkcscert" class="toclink">System SSL: Ensure PKCS #11 tokens contain complete certificate chains</a></div>
<div class="head3"><a id="ToC_171" href="#ssltlsr" class="toclink">System SSL: Modify applications to address disablement of SSL V3 and TLS session renegotiation</a></div>
<div class="head3"><a id="ToC_172" href="#csfserv" class="toclink">System SSL: Ensure all RACF user IDs that start SSL applications can access the CSFIQA resource of the CSFSERV class</a></div>
<div class="head2"><a id="ToC_173" href="#wq348" class="toclink">Cryptographic Services actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_174" href="#pmr74338" class="toclink">ICSF: Ensure the expected master key support is available</a></div>
<div class="head3"><a id="ToC_175" href="#pkichng" class="toclink">PKI Services: Change the time at which the daily maintenance task runs</a></div>
<div class="head1"><a id="ToC_176" href="#af1dfsm" class="toclink">DFSMS migration actions</a></div>
<div class="head2"><a id="ToC_177" href="#wq364" class="toclink">DFSMS actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_178" href="#ax3eisc" class="toclink">DFSMSdfp: Back up SMS control data sets</a></div>
<div class="head3"><a id="ToC_179" href="#listcsi" class="toclink">DFSMSdfp: Accommodate deletion of NOIMBED and NOREPLICAT LISTCAT command attributes</a></div>
<div class="head3"><a id="ToC_180" href="#capunca" class="toclink">DFSMSdfp: Modify exit routines to support 31-bit UCB addresses</a></div>
<div class="head3"><a id="ToC_181" href="#vsamirk" class="toclink">DFSMSdfp and DFSMSdss: Redefine existing VSAM data sets that contain the IMBED, REPLICATE, and KEYRANGE attributes</a></div>
<div class="head3"><a id="ToC_182" href="#replcim" class="toclink">DFSMSrmm: Replace CIM providers and CIM classes</a></div>
<div class="head3"><a id="ToC_183" href="#iggcat" class="toclink">DFSMSdfp: Define IGGCATxx parmlib member</a></div>
<div class="head2"><a id="ToC_184" href="#wq379" class="toclink">DFSMS actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_185" href="#af32b" class="toclink">DFSMSdfp: Ensure that the Language Environment runtime library is available for DLLs</a></div>
<div class="head3"><a id="ToC_186" href="#af32e" class="toclink">DFSMSdfp: Update SYS1.IMAGELIB</a></div>
<div class="head3"><a id="ToC_187" href="#af3d" class="toclink">DFSMSdss: Build the IPLable stand-alone DFSMSdss image</a></div>
<div class="head3"><a id="ToC_188" href="#copyvolid" class="toclink">DFSMSdss: Review changes to the messages that result from a COPY or RESTORE operation with COPYVOLID</a></div>
<div class="head3"><a id="ToC_189" href="#dadsmpro" class="toclink">	DFSMSdfp: Update operator procedures and system automation for new DADSM pre- and post-processing dynamic exits</a></div>
<div class="head3"><a id="ToC_190" href="#dfpcopy" class="toclink">	DFSMSdfp: Update procedures that use IEBDSCPY alias name to access IEBCOPY</a></div>
<div class="head3"><a id="ToC_191" href="#evalapp" class="toclink">DFSMSdfp: Evaluate applications and modify for EAV enhancements</a></div>
<div class="head3"><a id="ToC_192" href="#locanyp" class="toclink">DFSMSdfp: Accommodate new DCBE macro option</a></div>
<div class="head3"><a id="ToC_193" href="#recmlnk" class="toclink">DFSMSdss: Recompile and link-edit exit routines or applications that change options in the ADRUFO block</a></div>
<div class="head3"><a id="ToC_194" href="#modiobs" class="toclink">DFSMSdss: Modify applications to handle larger I/O buffers</a></div>
<div class="head3"><a id="ToC_195" href="#hsmpdatr" class="toclink">DFSMShsm: Accommodate the changed default of PDA trace during DFSMShsm startup</a></div>
<div class="head3"><a id="ToC_196" href="#hsmdsrec" class="toclink">DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION command DATASETRECOVERY parameter default</a></div>
<div class="head3"><a id="ToC_197" href="#hsmarc180" class="toclink">DFSMShsm: Replace user-defined patch with new SETSYS FASTREPLICATION command to enable ARC1809I messages</a></div>
<div class="head3"><a id="ToC_198" href="#hsmmsgie" class="toclink">DFSMShsm: Review messages changed from I (informational) to E (eventual action) type</a></div>
<div class="head3"><a id="ToC_199" href="#ptchmcvt" class="toclink">DFSMShsm: Remove patch that prevents SMS MVT chain rebuild</a></div>
<div class="head3"><a id="ToC_200" href="#multicds" class="toclink">DFSMShsm: Update operator procedure in the Multicluster CDS environment</a></div>
<div class="head3"><a id="ToC_201" href="#hsmdsscrsmem" class="toclink">DFSMShsm: Remove user-defined patch that disables or enables use of the DFSMSdss cross memory API</a></div>
<div class="head3"><a id="ToC_202" href="#hsmdssaddr" class="toclink">DFSMShsm: Configure your security system to permit started procedures using new address space identifier</a></div>
<div class="head3"><a id="ToC_203" href="#r12hsmquery" class="toclink">DFSMShsm: Update applications that depend on QUERY COPYPOOL output</a></div>
<div class="head3"><a id="ToC_204" href="#r12hsmlist" class="toclink">DFSMShsm: Update applications that depend on LIST command output</a></div>
<div class="head3"><a id="ToC_205" href="#hsmarcb" class="toclink">DFSMShsm: Accommodate the change of ARCBDEXT exit</a></div>
<div class="head2"><a id="ToC_206" href="#wq417" class="toclink">DFSMS actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_207" href="#armode64" class="toclink">DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement in DFSMS macros</a></div>
<div class="head3"><a id="ToC_208" href="#oamconf" class="toclink">DFSMSdfp: Run OAM configuration database migration job</a></div>
<div class="head3"><a id="ToC_209" href="#bindgra" class="toclink">DFSMSdfp: Run OAM DB2 BIND jobs</a></div>
<div class="head3"><a id="ToC_210" href="#useindz" class="toclink">DFSMSdfp: Use indirect zFS file system data set catalog support</a></div>
<div class="head3"><a id="ToC_211" href="#csichng" class="toclink">DFSMSdss: Accommodate Catalog Search Interface default change</a></div>
<div class="head3"><a id="ToC_212" href="#hsmarccat" class="toclink">DFSMShsm: Stop using the HOLD command to quiesce activity prior to control data set backup</a></div>
<div class="head1"><a id="ToC_213" href="#dfsomig" class="toclink">DFSORT migration actions</a></div>
<div class="head2"><a id="ToC_214" href="#wq429" class="toclink">DFSORT actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_215" href="#wq430" class="toclink">DFSORT actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_216" href="#dfsomsg" class="toclink">Update automation for changed DFSORT messages</a></div>
<div class="head2"><a id="ToC_217" href="#wq432" class="toclink">DFSORT actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_218" href="#mowrk" class="toclink">Use new MOWRK option to prevent the use of memory object storage for work space sort applications</a></div>
<div class="head3"><a id="ToC_219" href="#dynallo" class="toclink">Change the number of dynamically allocated work data sets using new DYNAPCT option</a></div>
<div class="head1"><a id="ToC_220" href="#dfsmiga" class="toclink">Distributed File Service migration actions</a></div>
<div class="head2"><a id="ToC_221" href="#wq437" class="toclink">Distributed File Service actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_222" href="#newdasd" class="toclink">zFS: Accommodate new DASD space requirements</a></div>
<div class="head3"><a id="ToC_223" href="#clonewith" class="toclink">zFS: Copy cloned file systems to a compatibility mode aggregate</a></div>
<div class="head3"><a id="ToC_224" href="#msaggreg" class="toclink">zFS: Copy data from zFS multi-file system aggregates to zFS compatibility mode aggregates</a></div>
<div class="head3"><a id="ToC_225" href="#filesyszfs" class="toclink">zFS: Ensure sysplex=filesys is available on all zFS R11 and R12 systems in a shared file system environment</a></div>
<div class="head3"><a id="ToC_226" href="#zfsvirtst" class="toclink">zFS: Verify virtual storage usage</a></div>
<div class="head2"><a id="ToC_227" href="#wq452" class="toclink">Distributed File Service actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_228" href="#disdfsc" class="toclink">DCE/DFS: Disable DFS Client initialization</a></div>
<div class="head2"><a id="ToC_229" href="#wq455" class="toclink">Distributed File Service actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head1"><a id="ToC_230" href="#ai1info" class="toclink">Infoprint Server migration actions</a></div>
<div class="head2"><a id="ToC_231" href="#wq456" class="toclink">Infoprint Server actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_232" href="#pispace" class="toclink">Increase space in the Printer Inventory file system</a></div>
<div class="head3"><a id="ToC_233" href="#remv2pi" class="toclink">Remove Version 2 Printer Inventory files at fallback to z/OS V1R11</a></div>
<div class="head3"><a id="ToC_234" href="#javaipp" class="toclink">Upgrade Java support for IPP Server</a></div>
<div class="head2"><a id="ToC_235" href="#wq465" class="toclink">Infoprint Server actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_236" href="#ai3svco" class="toclink">Remount the Printer Inventory and copy files that were customized</a></div>
<div class="head3"><a id="ToC_237" href="#regsizeao" class="toclink">Update or remove the region size in the AOPSTART startup procedure</a></div>
<div class="head3"><a id="ToC_238" href="#isxml" class="toclink">Upgrade XML for Infoprint Central</a></div>
<div class="head3"><a id="ToC_239" href="#btemode" class="toclink">Migrate from IP PrintWay basic mode to extended mode</a></div>
<div class="head2"><a id="ToC_240" href="#wq474" class="toclink">Infoprint Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_241" href="#runaops" class="toclink">Run aopsetup</a></div>
<div class="head3"><a id="ToC_242" href="#remv1pi" class="toclink">Remove Version 1 Printer Inventory files after deploying z/OS V1R13</a></div>
<div class="head1"><a id="ToC_243" href="#aj1ispf" class="toclink">ISPF migration actions</a></div>
<div class="head2"><a id="ToC_244" href="#wq479" class="toclink">ISPF actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_245" href="#wq480" class="toclink">ISPF actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_246" href="#wq481" class="toclink">ISPF actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_247" href="#ispf13" class="toclink">Review changes to ISPF panels for new allocation of non-SMS-managed sequential data set</a></div>
<div class="head1"><a id="ToC_248" href="#ah1jes2" class="toclink">JES2 migration actions</a></div>
<div class="head2"><a id="ToC_249" href="#wq483" class="toclink">JES2 actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_250" href="#exitchg" class="toclink">Update code to remove references to PDBLENG</a></div>
<div class="head3"><a id="ToC_251" href="#pismult" class="toclink">Ensure calls to JES Property Information Services SSI can handle multiple members</a></div>
<div class="head2"><a id="ToC_252" href="#wq486" class="toclink">JES2 actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_253" href="#wq487" class="toclink">JES2 actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_254" href="#activ11" class="toclink">Activate z11 mode</a></div>
<div class="head1"><a id="ToC_256" href="#al1jes3" class="toclink">JES3 migration actions</a></div>
<div class="head2"><a id="ToC_257" href="#wq492" class="toclink">JES3 actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_258" href="#dlogsplit" class="toclink">Modify code that depends on the format of suppressed split messages in the DLOG</a></div>
<div class="head2"><a id="ToC_259" href="#wq494" class="toclink">JES3 actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_260" href="#autoflsh" class="toclink">Avoid redundant *S main,FLUSH command in response to XCF messages</a></div>
<div class="head3"><a id="ToC_261" href="#moddatlorec" class="toclink">Modify code that uses DATLOREC and DATINPTR (IATYDAT) as a  programming interface</a></div>
<div class="head3"><a id="ToC_262" href="#jes3msg" class="toclink">Update automation that handles message IAT3100</a></div>
<div class="head2"><a id="ToC_263" href="#wq498" class="toclink">JES3 actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head1"><a id="ToC_264" href="#am1lenv" class="toclink">Language Environment migration actions</a></div>
<div class="head2"><a id="ToC_265" href="#wq499" class="toclink">Language Environment actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_266" href="#wq500" class="toclink">Language Environment actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_267" href="#am3le2" class="toclink">Determine the impact of added and changed runtime options</a></div>
<div class="head3"><a id="ToC_268" href="#am3le2a" class="toclink">Update the CSD based on the newest CEECCSD</a></div>
<div class="head3"><a id="ToC_269" href="#am3le2b" class="toclink">Update Language Environment load modules in the LPA</a></div>
<div class="head3"><a id="ToC_270" href="#ceeprmset" class="toclink">Convert to CEEPRMxx to set system-level default runtime options</a></div>
<div class="head3"><a id="ToC_271" href="#dceecom" class="toclink">Examine programs that read output when a D CEE command is issued</a></div>
<div class="head3"><a id="ToC_272" href="#nonover" class="toclink">Set runtime options as overrideable or nonoverrideable in CEEPRMxx parmlib member</a></div>
<div class="head2"><a id="ToC_273" href="#wq507" class="toclink">Language Environment actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_274" href="#leclerop" class="toclink">Examine programs that read output from a CICS CLER transaction</a></div>
<div class="head3"><a id="ToC_275" href="#convtbl" class="toclink">Use Unicode Services to create conversion tables</a></div>
<div class="head1"><a id="ToC_276" href="#ab1bser" class="toclink">Library Server migration actions</a></div>
<div class="head2"><a id="ToC_277" href="#wq511" class="toclink">Library Server actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_278" href="#libsb1i" class="toclink">Library Server actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_279" href="#ab3conf" class="toclink">Copy Library Server configuration files</a></div>
<div class="head3"><a id="ToC_280" href="#ab3note" class="toclink">Copy Library Server notes files</a></div>
<div class="head2"><a id="ToC_281" href="#wq514" class="toclink">Library Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head1"><a id="ToC_282" href="#ao1rmf" class="toclink">RMF migration actions</a></div>
<div class="head2"><a id="ToC_283" href="#wq515" class="toclink">RMF actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_284" href="#wq516" class="toclink">RMF actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_285" href="#msgerb81" class="toclink">Check your automation for Monitor III messages ERB812I and ERB813I</a></div>
<div class="head2"><a id="ToC_286" href="#wq518" class="toclink">RMF actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_287" href="#rmflater" class="toclink">Use an RMF Monitor III reporter version equal to or later than your RMF Monitor III gatherer version</a></div>
<div class="head3"><a id="ToC_288" href="#psdrept" class="toclink">Determine need of SMF data collection for Postprocessor Serialization Delay report</a></div>
<div class="head3"><a id="ToC_289" href="#irqueue" class="toclink">Retrieve the distribution of the IN-READY QUEUE</a></div>
<div class="head1"><a id="ToC_290" href="#ap1sdsf" class="toclink">SDSF migration actions</a></div>
<div class="head2"><a id="ToC_291" href="#wq523" class="toclink">SDSF actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a id="ToC_292" href="#wq524" class="toclink">SDSF actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_293" href="#ax3exit" class="toclink">Review and reassemble user exit routines</a></div>
<div class="head3"><a id="ToC_294" href="#ax3assm" class="toclink">Use dynamic statements for ISFPARMS to avoid reassembly</a></div>
<div class="head2"><a id="ToC_295" href="#wq529" class="toclink">SDSF actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_296" href="#wbmqsdsf" class="toclink">Update configuration for sysplex support</a></div>
<div class="head3"><a id="ToC_297" href="#operlgcol" class="toclink">Review colors on the OPERLOG panel</a></div>
<div class="head3"><a id="ToC_298" href="#pnchrdr" class="toclink">Set the format of device names on the Punch and Reader panels</a></div>
<div class="head3"><a id="ToC_299" href="#definit" class="toclink">Set a default for the Initiators panel</a></div>
<div class="head3"><a id="ToC_300" href="#prntpnl" class="toclink">Set the format of device names on the Printers panel</a></div>
<div class="head3"><a id="ToC_301" href="#msg770w" class="toclink">Update batch programs or REXX execs for changes to message ISF770W</a></div>
<div class="head3"><a id="ToC_302" href="#operlog" class="toclink">Set the view of the OPERLOG</a></div>
<div class="head1"><a id="ToC_303" href="#aq1secs" class="toclink">Security Server migration actions</a></div>
<div class="head2"><a id="ToC_304" href="#wq537" class="toclink">Security Server actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_305" href="#distname" class="toclink">Normalize user names specified as X.500 distinguished names in distributed identity filters</a></div>
<div class="head2"><a id="ToC_310" href="#wq543" class="toclink">Security Server actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_311" href="#aq3cdcn" class="toclink">Check for duplicate class names</a></div>
<div class="head3"><a id="ToC_312" href="#wq546" class="toclink">Normalize user names specified as X.500 distinguished names in distributed identity filters</a></div>
<div class="head2"><a id="ToC_313" href="#wq547" class="toclink">Security Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_314" href="#aq3dbte" class="toclink">Update database templates</a></div>
<div class="head3"><a id="ToC_315" href="#wq550" class="toclink">Normalize user names specified as X.500 distinguished names in distributed identity filters</a></div>
<div class="head3"><a id="ToC_316" href="#digicert" class="toclink">Use new RACDCERT GENCERT and REKEY defaults for digital certificates</a></div>
<div class="head1"><a id="ToC_317" href="#ar1smpe" class="toclink">SMP/E migration actions</a></div>
<div class="head2"><a id="ToC_318" href="#wq554" class="toclink">SMP/E actions to perform after installing SMP/E V3R6 (z/OS V1R13 SMP/E) but before starting to use it</a></div>
<div class="head3"><a id="ToC_319" href="#smpecmd" class="toclink">Authorize use of SMP/E commands and services</a></div>
<div class="head2"><a id="ToC_320" href="#wq556" class="toclink">SMP/E actions to perform after starting to use SMP/E V3R6 (z/OS V1R13 SMP/E)</a></div>
<div class="head1"><a id="ToC_321" href="#tsoemig" class="toclink">TSO/E migration actions</a></div>
<div class="head2"><a id="ToC_322" href="#wq557" class="toclink">TSO/E actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_323" href="#tsosynt" class="toclink">Do not rely on TSO/E to check the syntax of passwords</a></div>
<div class="head2"><a id="ToC_324" href="#wq559" class="toclink">TSO/E actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_325" href="#wq560" class="toclink">TSO/E actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_326" href="#tsosmsinfo" class="toclink">Specify the SMSINFO keyword on LISTDSI to retrieve detailed PDSE information</a></div>
<div class="head3"><a id="ToC_327" href="#dsrecmd" class="toclink">Accommodate changes for data sets allocated by the RECEIVE command</a></div>
<div class="head1"><a id="ToC_328" href="#ac1ccpp" class="toclink">XL C/C++ migration actions</a></div>
<div class="head2"><a id="ToC_329" href="#wq564" class="toclink">XL C/C++ actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_330" href="#revappl" class="toclink">Review the XL C/C++ Migration Guide for the Application Programmer</a></div>
<div class="head2"><a id="ToC_331" href="#wq566" class="toclink">XL C/C++ actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_332" href="#wq567" class="toclink">XL C/C++ actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_333" href="#ipaobno" class="toclink">Update IPA compiler option IPA(OBJECT)</a></div>
<div class="head1"><a id="ToC_334" href="#as1unss" class="toclink">z/OS UNIX migration actions</a></div>
<div class="head2"><a id="ToC_335" href="#wq569" class="toclink">z/OS UNIX actions to perform before installing z/OS V1R13</a></div>
<div class="head3"><a id="ToC_336" href="#zmountusr" class="toclink">Update invocations of /usr/sbin/mount commands</a></div>
<div class="head3"><a id="ToC_337" href="#binunmnt" class="toclink">Update invocations of /usr/sbin/unmount commands</a></div>
<div class="head3"><a id="ToC_338" href="#bpx1bpx4" class="toclink">Review programs that invoke the BPX1EXM/BPX4EXM callable service</a></div>
<div class="head3"><a id="ToC_339" href="#shelluti" class="toclink">Accommodate the new Shell and Utilities version of the tsocmd command</a></div>
<div class="head3"><a id="ToC_340" href="#maxsock" class="toclink">Remove MAXSOCKETS values from AF_UNIX in the BPXPRMxx parmlib member</a></div>
<div class="head3"><a id="ToC_341" href="#conscal" class="toclink">Discontinue use of z/OS UNIX System Services Connection Scaling</a></div>
<div class="head3"><a id="ToC_342" href="#hfs2zfs" class="toclink">Migrate from HFS file systems to zFS file systems</a></div>
<div class="head2"><a id="ToC_343" href="#wq585" class="toclink">z/OS UNIX actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_344" href="#bpxmount" class="toclink">Update invocations of MOUNT statements in the BPXPRMxx parmlib member</a></div>
<div class="head3"><a id="ToC_345" href="#symblinks" class="toclink">Accommodate changes to support read-only z/OS root for the z/OS UNIX System Services cron, mail, and uucp utilities</a></div>
<div class="head2"><a id="ToC_346" href="#wq591" class="toclink">z/OS UNIX actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a id="ToC_347" href="#invrexx" class="toclink">Discontinue use of invalid REXX variables in z/OS UNIX syscalls</a></div>
<div class="head3"><a id="ToC_348" href="#skulker" class="toclink">Consider skulker invocations because of updated restriction</a></div>
<div class="head3"><a id="ToC_349" href="#bpxuniq" class="toclink">Use the BPX.UNIQUE.USER profile instead of BPX.DEFAULT.USER</a></div>
<div class="head1"><a id="ToC_350" href="#wq597" class="toclink">Index for Migration</a></div>
</div>
<h1 id="abstract">Abstract for Migration</h1>
<p>This information supports z/OS&reg; (5694-A01).</p>
<p><strong>Purpose of this information</strong></p>
<p>This information describes how to migrate <strong>to</strong> z/OS Version 1 Release 13 (V1R13) <strong>from</strong> the following releases: </p>
<ul>
<li>z/OS V1R12</li>
<li>z/OS V1R11</li></ul>
<p>This information does not explain how to exploit new functions
in z/OS. For that information,
see the information units specific to the z/OS base elements and optional features.</p>
<p><strong>Who should read this information</strong></p>
<p>This information is intended for system analysts, system programmers,
system administrators, security administrators, network administrators,
database administrators, and other members of an information technology
team who have experience installing and managing z/OS, and want to plan for and implement the installation
of z/OS V1R13.</p>
<p><strong>Related information</strong></p>
<p>See >z/OS Introduction and Release Guide</a> for
an introduction to z/OS and
an overview of the new functions in each release of z/OS.</p>
<p>See >z/OS Planning for Installation</a> for a summary of installation changes
in each release of z/OS, driving
system hardware and software requirements, target system hardware
and software requirements, the coexistence-migration-fallback policy,
and considerations for planning future installations.</p>
<p><strong>Conventions and terminology used in this information</strong></p>
<p>When this information refers to <span class="bold-italic">IBM&reg; System z&reg;</span> servers without stating a specific
server, it refers to all of the following servers:</p>
<ul>
<li>IBM zEnterprise&trade;<sup>TM</sup> z114 (z114)</li>
<li>IBM zEnterprise<sup>TM</sup> z196 (z196)</li>
<li>IBM System z9&reg; Enterprise Class (z9 EC),
formerly the IBM System z9 109 (z9-109)</li>
<li>IBM System z9 Business Class (z9 BC)</li>
<li>IBM eServer&trade; zSeries&reg; 990
(z990)</li>
<li>IBM eServer zSeries 890
(z890)</li>
<li>IBM eServer zSeries 900
(z900)</li>
<li>IBM eServer zSeries 800
(z800)</li></ul>
<p>Important terms you should understand are:</p>
<ul>
<li><span class="bold-italic">Migration.</span> Migration is the first of two stages in an
upgrade to a new release of z/OS.
(The second stage is exploitation.) During this stage you install
your new system with the objective of making it functionally compatible
with the previous system. After a successful migration, the applications
and resources on the new system function the same way (or similar
to the way) they did on the old system or, if that is not possible,
in a way that accommodates the new system differences so that existing
workloads can continue to run. Migration does not include exploitation
of new functions except for new functions that are now required.</li>
<li><span class="bold-italic">Exploitation.</span> Exploitation is the
second of two stages in an upgrade to a new release of z/OS. (The first stage is migration.)
During this stage you do whatever customizing and programming are
necessary to take advantage of (exploit) the enhancements available
in the new release.</li>
<li><span class="bold-italic">Coexistence.</span> Coexistence is the situation
in which two or more systems at different software levels share resources.
The resources could be shared at the same time by different systems
in a multisystem configuration, or they could be shared over a period
of time by the same system in a single-system configuration.
<p>Examples
of coexistence are two different JES releases sharing a spool, two
different service levels of DFSMSdfp sharing catalogs, multiple levels
of SMP/E processing SYSMODS packaged to exploit the latest enhancements,
or an older level of the system using the updated system control files
of a newer level (even if new function has been exploited in the newer
level).</p>
<p>The sharing of resources is inherent in multisystem
configurations that involve Parallel Sysplex&reg; implementations. But other types of configurations can
have resource sharing too. Examples of configurations where resource
sharing can occur are:</p>
<ul>
<li>A single processor that is time-sliced to run different levels
of the system, such as during different times of the day</li>
<li>A single processor running multiple images by means of logical
partitions (LPARs)</li>
<li>Multiple images running on several different processors in either Parallel Sysplex or
non-Parallel Sysplex configurations</li></ul>
<p>The way in which you make it possible for earlier-level
systems to coexist with the most current level is to install coexistence
and fallback PTFs on the earlier-level systems.</p></li>
<li><span class="bold-italic">Fallback.</span> Fallback is a return to
the prior level of a system. Fallback can be appropriate if you migrate
to a new release and, during testing, encounter severe problems that
can be resolved by backing out the new release. By installing coexistence
and fallback PTFs on the &quot;old&quot; system before you migrate, the
old system can tolerate changes that were made by the new system during
testing.</li></ul>
<p>To identify the timing of migration actions, this information uses
three types of headings:</p>
<ul>
<li><span class="bold-italic">Actions to perform Before installing z/OS V1R13.</span> These are migration
actions that you perform on your current system, either because they
require the current system or because they are possible on the current
system. You do not need the z/OS V1R13
level of code to make these changes, and the changes do not require
the z/OS V1R13 level of code
to run once they are made. Examples are installing coexistence and
fallback PTFs on your current system, discontinuing use of hardware
or software that will no longer be supported, and starting to use
existing functions that were optional on prior releases but required
in z/OS V1R13.</li>
<li><span class="bold-italic">Actions to perform before the first IPL
of z/OS V1R13.</span> These are
migration actions that you perform after you have installed z/OS V1R13 but before the first
time you IPL. These actions require the z/OS V1R13
level of code to be installed but do not require it to be active.
That is, you need the z/OS V1R13
programs, utilities, and samples in order to perform the migration
actions, but the z/OS V1R13
system does not have to be IPLed in order for the programs to run.
Examples are running sysplex utilities and updating the RACF&reg; database template.
<p>It is
possible to perform some of the migration actions in this category
even earlier. If you prepare a system on which you will install z/OS V1R13 by making a clone of
your old system, you can perform migration actions that involve customization
data on this newly prepared system before installing z/OS V1R13 on it. Examples of such migration actions
are updating configuration files and updating automation scripts.</p></li>
<li><span class="bold-italic">Actions to perform after the first IPL
of z/OS V1R13.</span> These are
migration actions that you can perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these
actions. An example is issuing RACF commands
related to new functions. Note that the term &quot;first IPL&quot; does
not mean that you have to perform these actions after the very first
IPL, but rather that you need z/OS V1R13
to be active to perform the task. You might perform the task quite
a while after the first IPL.</li></ul>
<p>Each migration action within the headings above is presented using
the following standard format:</p>
<ul>
<li>A title that identifies the migration action.</li>
<li><span class="bold-italic">Description.</span> This is a brief description
of the functional change that caused the migration action.</li>
<li><span class="bold-italic">Element or feature.</span> This is the name
of the base element or optional feature that changed.</li>
<li><span class="bold-italic">When change was introduced.</span> This
is the z/OS release in which
the change was introduced.</li>
<li><span class="bold-italic">Applies to migration from.</span> The migration
action is relevant if you are migrating from this release.</li>
<li><span class="bold-italic">Timing.</span> This is when you should perform
the migration action. There are three categories: before installing z/OS, before first IPL, or after
first IPL. (For SMP/E there are two categories: after installing SMP/E
but before starting to use it, and after starting to use SMP/E.)</li>
<li><span class="bold-italic">Is the migration action required?</span> This
question refers to the migration action identified by the title. The
answer can be one of the following:
<ul>
<li><em>Yes.</em> The migration action is required
in all cases.</li>
<li><em>Yes, if...</em> The migration action
is required only in a certain case. Most of the migration actions
are in this category.</li>
<li><em>No, but recommended...</em> The migration
action is not required but is recommended because it is a good programming
practice, because it will be required in the future, or because it
resolves unacceptable system behavior (such as poor usability or poor
performance) even though resolution might require a change in behavior.</li></ul></li>
<li><span class="bold-italic">Target system hardware requirements.</span> This
is hardware required by the functional change. It could be processor
and peripheral devices; drivers, engineering changes, or patches needed;
or specific hardware functions that must be active.</li>
<li><span class="bold-italic">Target system software requirements.</span> This
is software required by the functional change. It could be z/OS optional features, software
products, and PTFs that are needed on the target system, as well as
specific software functions that must be active.</li>
<li><span class="bold-italic">Other system (coexistence or fallback)
requirements.</span> These are requirements placed on an earlier release
by the functional change in the new release. The earlier release could
be running on a system that shares resources (coexists) with the new
system or it could be the release from which you are migrating (and
to which you might want to fall back).</li>
<li><span class="bold-italic">Restrictions.</span> These are any known
limits on how the function can be used.</li>
<li><span class="bold-italic">System impacts.</span> These are any known
impacts of using the function, such as increased storage or more time
required to run.</li>
<li><span class="bold-italic">Steps to take.</span> This is what you have
to do to perform the migration action.</li>
<li><span class="bold-italic">Reference information.</span> This is a
pointer to additional information that helps you perform the migration
action.</li></ul>
<p>The order in which the migration actions are presented does not
imply importance or chronology.</p>
<h1 id="soasoc">Summary of changes</h1><a id="idx2"></a><a id="idx3"></a>
<p>This topic summarizes the changes made to this document.</p>
<h2 id="wq1">Changes made in z/OS Version 1 Release 13 as updated September
2012</h2>
<p>This document contains information previously presented in GA22-7499-20,
which supports z/OS Version
1 Release 13.</p>
<div>
<span class="pblktitle">New information</span>
<p>Information is provided for the new server IBM zEnterprise zEC12 . See <a href="#znext2">Migrate to an IBM zEnterprise zEC12 server</a>.</p>
<p>The following migration actions are new:</p>
<ul>
<li>Prepare for z/OS V1R13
RSM Enablement Offering Web deliverable. See that topic in <a href="#znextaft2">Migration and exploitation considerations for zEC12 server
functions</a>.</li>
<li>BCP
<ul>
<li>Migration action <a href="#nucleus">Accommodate increase in nucleus size for  the z/OS V1R13 RSM Enablement Offering Web deliverable</a> is new.</li>
<li>Migration action <a href="#esqa">Accommodate increase in ESQA with the z/OS V1R13 RSM Enablement Offering Web deliverable</a> is new.</li>
<li>Migration action <a href="#grsficon">Migrate to GRS-managed FICON CTCs</a> is new.</li></ul></li>
<li>Communications Server
<ul>
<li>Migration action <a href="#tcpip">IP and SNA Services: Remove TCPIPDS1 and ISTITDS1 specification
from dump commands</a> is new.</li></ul></li>
<li>DFSMS
<ul>
<li>Migration action <a href="#copyvolid">DFSMSdss: Review changes to the messages that result from a
COPY or RESTORE operation with COPYVOLID</a> is new.</li></ul></li>
<li>ISPF
<ul>
<li>Migration action <a href="#ispf13">Review changes to ISPF panels for new allocation of non-SMS-managed
sequential data set</a> is new.</li></ul></li>
<li>TSO/E
<ul>
<li>Migration action <a href="#tsosmsinfo">Specify the SMSINFO keyword on LISTDSI to retrieve detailed
PDSE information</a> is new.</li></ul></li></ul></div>
<div>
<span class="pblktitle">Changed information</span></div>
<ul>
<li>
<p><a href="#eafwoma">Elements and features that do not have migration actions</a> has been updated.</p></li>
<li>For changes to z/OS messages
and interfaces, including parmlib members, for this release, see <cite></cite>.</li></ul>
<p>This document contains terminology, maintenance, and editorial
changes. Technical changes or additions to the text and illustrations
are indicated by a vertical line to the left of the change.</p>
<h2 id="wq4">Changes made in z/OS Version 1 Release 13 as updated April
2012</h2>
<p>This document contains information previously presented in <cite>z/OS MVS Migration</cite>, GA22-7499-19, which supports z/OS Version 1 Release 13.</p>
<div>
<span class="pblktitle">New information</span>
<ul>
<li>The following migration actions are new:
<ul>
<li>BCP
<ul>
<li><a href="#logrecsum">Adjust LOGRECSUMMARY statement value in CEAPRMxx member</a>.</li>
<li><a href="#pfamax">Add to the maximum number of open files under z/OS UNIX Systems
Services for PFA</a>.</li></ul></li>
<li>Communications Server
<ul>
<li><a href="#ftpdaemon">IP Services: Accommodate new format of FTP daemon console messages
that no longer are prefixed with '+'</a>.</li></ul></li>
<li>SSL
<ul>
<li><a href="#csfserv">System SSL: Ensure all RACF user
IDs that start SSL applications can access the CSFIQA resource of
the CSFSERV class</a>.</li></ul></li>
<li>JES3
<ul>
<li><a href="#jes3msg">Update automation that handles message IAT3100</a>.</li></ul></li></ul></li></ul></div>
<div>
<span class="pblktitle">Changed information</span>
<ul>
<li><a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a> has been updated.</li>
<li><a href="#at3gena">Set up an IPCS environment</a> has been updated.</li>
<li><a href="#mignext">Migrate to an IBM zEnterprise z196 or z114
server</a> has been updated.</li>
<li><a href="#warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</a> has been updated.</li>
<li><a href="#oa34731">Issue commands from the system console regardless of problem
determination mode</a> has been updated.</li>
<li><a href="#grsauthql">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames</a> has been updated.</li>
<li><a href="#modiobs">DFSMSdss: Modify applications to handle larger I/O buffers</a> has been updated.</li>
<li><a href="#oamconf">DFSMSdfp: Run OAM configuration database migration job</a> has been updated.</li>
<li><a href="#disdfsc">DCE/DFS: Disable DFS Client initialization</a> has been updated.</li>
<li><a href="#dlogsplit">Modify code that depends on the format of suppressed split
messages in the DLOG</a> has been updated.</li>
<li><a href="#ceeprmset">Convert to CEEPRMxx to set system-level default runtime
options</a> has been updated.</li></ul></div>
<p>This document contains terminology, maintenance, and editorial
changes. Technical changes or additions to the text and illustrations
are indicated by a vertical line to the left of the change.</p>
<h2 id="wq7">Changes made in z/OS Version 1 Release 13</h2>
<p>This document contains information previously presented in <cite>z/OS MVS Migration</cite>, GA22-7499-18, which supports z/OS Version 1 Release 12.</p>
<div>
<span class="pblktitle">New information</span>
<ul>
<li>The following migration actions are new:
<ul>
<li>Migration actions for everyone
<ul>
<li><a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</li></ul></li>
<li>BCP
<ul>
<li><a href="#warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</a>.</li>
<li><a href="#dasdpfa">Define DASD storage for Predictive Failure Analysis</a>.</li>
<li><a href="#sodbcpii">Migrate from SNMP to z/OS BCPii
for communication to the HMC or SE</a>.</li>
<li><a href="#oneblank">Verify that at  least one blank follows all major keyword statements
in CONSOLExx</a>.</li>
<li><a href="#cplibpath">Upgrade Java support
for Capacity Provisioning</a>.</li>
<li><a href="#pgserpro">Discontinue use of PGSER to protect and unprotect the READONLY
nucleus</a>.</li>
<li><a href="#pduu">Remove references to the MTFTPS utility</a>.</li>
<li><a href="#oa35357">Change value for ARM restart processing</a>.</li>
<li><a href="#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a>.</li>
<li><a href="#llaauto">Update LLA for automation</a>.</li>
<li><a href="#operloge">Accommodate OPERLOG EMCS console name change</a>.</li>
<li><a href="#conparm">Adjust CON= system parameter to accommodate default change</a>.</li>
<li><a href="#hyperz196">Accommodate HiperDispatch default of YES on IBM zEnterprise zEC12 and IBM zEnterprise (z196 and z114)</a>.</li>
<li><a href="#commndxx">Start Runtime Diagnostics at system initialization</a>.</li>
<li><a href="#oa34731">Issue commands from the system console regardless of problem
determination mode</a>.</li>
<li><a href="#javacpm">Update Capacity Provisioning Manager parameters to use CIM
client for Java Version 2</a>.</li>
<li><a href="#grsauthql">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames</a>.</li>
<li><a href="#cmdsabe">Examine use of the CMDS ABEND command</a>.</li>
<li><a href="#rtdpfa">Ensure Runtime Diagnostics is installed before invoking Predictive
Failure Analysis</a>.</li></ul></li>
<li>Communications Server
<ul>
<li><a href="#defidresolve">IP Services: Define a user ID for the system resolver with
an associated OMVS segment</a>.</li>
<li><a href="#commsids">IP Services: Understand and prepare for expanded Intrusion
Detection Services</a>.</li>
<li><a href="#ftchkpwd">IP Services: Ensure that the FTP user exit routine FTCHKPWD
tolerates an additional parameter</a>.</li>
<li><a href="#portrnge">IP Services: Understand change in VIPARANGE security
verification processing</a>.</li>
<li><a href="#asgnbuf">SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests
do not exceed 500 images for a single CSM buffer</a>.</li>
<li><a href="#viparange">IP Services: Review VIPARANGE definitions</a>.</li>
<li><a href="#vitrelocate">SNA Services: Adjust to the relocation of the VTAM internal trace table</a>.</li></ul></li>
<li>Cryptographic Services
<ul>
<li><a href="#icsfcsfpu">ICSF: Ensure the CSFPUTIL utility is not used to initialize
a PKDS</a>.</li>
<li><a href="#pkcscert">System SSL: Ensure PKCS #11 tokens contain complete certificate
chains</a>.</li>
<li><a href="#pmr74338">ICSF: Ensure the expected master key support is available</a>.</li></ul></li>
<li>DFSMS
<ul>
<li><a href="#listcsi">DFSMSdfp: Accommodate deletion of NOIMBED and NOREPLICAT
LISTCAT command attributes</a>.</li>
<li><a href="#dadsmpro">	DFSMSdfp: Update operator procedures and system automation
for new DADSM pre- and post-processing dynamic exits</a>.</li>
<li><a href="#dfpcopy">	DFSMSdfp: Update procedures that use IEBDSCPY alias name to
access IEBCOPY</a>.</li>
<li><a href="#hsmpdatr">DFSMShsm: Accommodate the changed default of PDA trace during
DFSMShsm startup</a>.</li>
<li><a href="#hsmdsrec">DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION command
DATASETRECOVERY parameter default</a>.</li>
<li><a href="#hsmarc180">DFSMShsm: Replace user-defined patch with new SETSYS FASTREPLICATION
command to enable ARC1809I messages</a>.</li>
<li><a href="#hsmmsgie">DFSMShsm: Review messages changed from I (informational) to
E (eventual action) type</a>.</li>
<li><a href="#ptchmcvt">DFSMShsm: Remove patch that prevents SMS MVT chain rebuild</a>.</li>
<li><a href="#multicds">DFSMShsm: Update operator procedure in the Multicluster CDS
environment</a>.</li>
<li><a href="#armode64">DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement
in DFSMS macros</a>.</li>
<li><a href="#oamconf">DFSMSdfp: Run OAM configuration database migration job</a>.</li>
<li><a href="#csichng">DFSMSdss: Accommodate Catalog Search Interface default change</a>.</li>
<li><a href="#hsmarccat">DFSMShsm: Stop using the HOLD command to quiesce activity prior
to control data set backup</a>.</li></ul></li>
<li>Distributed File Service
<ul>
<li><a href="#newdasd">zFS: Accommodate new DASD space requirements</a>.</li>
<li><a href="#clonewith">zFS: Copy cloned file systems to a compatibility mode aggregate</a>.</li>
<li><a href="#msaggreg">zFS: Copy data from zFS multi-file system aggregates to zFS
compatibility mode aggregates</a>.</li>
<li><a href="#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a>.</li>
<li><a href="#zfsvirtst">zFS: Verify virtual storage usage</a>.</li>
<li><a href="#disdfsc">DCE/DFS: Disable DFS Client initialization</a>.</li></ul></li>
<li>Infoprint Server
<ul>
<li><a href="#regsizeao">Update or remove the region size in the AOPSTART startup procedure</a>.</li></ul></li>
<li>JES3
<ul>
<li><a href="#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a>.</li></ul></li>
<li>Language Environment
<ul>
<li><a href="#ceeprmset">Convert to CEEPRMxx to set system-level default runtime
options</a>.</li></ul></li>
<li>RMF
<ul>
<li><a href="#msgerb81">Check your automation for Monitor III messages ERB812I and
ERB813I</a>.</li>
<li><a href="#psdrept">Determine need of SMF data collection for Postprocessor
Serialization Delay report</a>.</li></ul></li>
<li>SDSF
<ul>
<li><a href="#wbmqsdsf">Update configuration for sysplex support</a>.</li>
<li><a href="#operlgcol">Review colors on the OPERLOG panel</a>.</li>
<li><a href="#pnchrdr">Set the format of device names on the Punch and Reader panels</a>.</li></ul></li>
<li>Security Server
<ul>
<li><a href="#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</li></ul></li>
<li>z/OS UNIX
<ul>
<li><a href="#zmountusr">Update invocations of /usr/sbin/mount commands</a>.</li>
<li><a href="#binunmnt">Update invocations of /usr/sbin/unmount commands</a>.</li>
<li><a href="#bpx1bpx4">Review programs that invoke the BPX1EXM/BPX4EXM callable service</a>.</li>
<li><a href="#bpxmount">Update invocations of MOUNT statements in the BPXPRMxx parmlib
member</a>.</li>
<li><a href="#symblinks">Accommodate changes to support read-only z/OS root for the z/OS UNIX System
Services cron, mail, and uucp utilities</a>.</li>
<li><a href="#invrexx">Discontinue use of invalid REXX variables in z/OS UNIX syscalls</a>.</li></ul></li></ul></li></ul></div>
<div>
<span class="pblktitle">Changed information</span>
<ul>
<li>z/OS Management Facility
(z/OSMF) migration actions are located in "Migrating from an earlier
release of z/OSMF" in >IBM z/OS Management Facility Configuration Guide</a>.</li>
<li><a href="#eafwoma">Elements and features that do not have migration actions</a> has been updated.</li>
<li>Changes<a href="#znextaft2">Migration and exploitation considerations for zEC12 server
functions</a></li>
<li><a href="#uplochk">Update your check customization for modified IBM Health Checker for z/OS checks</a> has been updated to reflect new, changed,
and deleted IBM for Health Checker
for z/OS checks.</li>
<li><a href="#ldtab1">Table 3</a> has been updated.</li>
<li><a href="#dsadded">Table 4</a> has been updated.</li>
<li><a href="#znextsod">Accommodate functions for the z196 and z114 servers to be discontinued
on future servers</a> has been updated to include information
about the new IBM zEnterprise 114 (z114) server.</li>
<li>The z/OS V1R12 migration
action, &quot;Migrate to an IBM zEnterprise 196 (z196) server,&quot;
has been undated to include information about the new IBM zEnterprise 114
(z114 server) and is now titled, <a href="#mignext">Migrate to an IBM zEnterprise z196 or z114
server</a> .</li>
<li>&quot;IP Services: Migrate from DNS BIND 9.2.0&quot; and replaced
with <a href="#sodbind">IP Services: Migrate from BIND 9.2.0</a>.</li>
<li><a href="#am3le2">Determine the impact of added and changed runtime options</a> has been updated.</li>
<li>Also, see additional changes indicated by the change bar | in
the margin.</li></ul></div>
<div>
<span class="pblktitle">Deleted information</span>
<ul>
<li>Approximately 80 migration actions have been deleted because they
applied to migrations from z/OS V1R10,
and that release is not supported for migration to z/OS V1R13.</li>
<li>z/OS Management Facility
(z/OSMF) migration actions can be found in "Migrating from an earlier
release of z/OSMF" in >IBM z/OS Management Facility Configuration Guide</a>.</li></ul></div>
<p>This document contains terminology, maintenance, and editorial
changes. Technical changes or additions to the text and illustrations
are indicated by a vertical line to the left of the change.</p>
<h1 id="chintro">Introduction</h1>
<p>Upgrading to a new release of z/OS is
usually a two-stage process: </p>
<ul>
<li><strong>Stage 1: Migration.</strong> During this stage you
install your new system with the objective of making it functionally
compatible with the previous system. After a successful migration,
the applications and resources on the new system function the same
way (or similar to the way) they did on the old system or, if that
is not possible, in a way that accommodates the new system differences
so that existing workloads can continue to run. Migration does not
include exploitation of new functions except for new functions that
are now required.</li>
<li><strong>Stage 2: Exploitation.</strong> During this stage
you do whatever customizing and programming are necessary to take
advantage of (exploit) the enhancements available in the new release.</li></ul>
<p>This document describes what you must do
to migrate from either of the two releases that are supported for
direct migration to z/OS V1R13: </p>
<ul>
<li>z/OS V1R12</li>
<li>z/OS V1R11</li></ul><a id="idx4"></a><a id="idx5"></a><a id="idx6"></a><a id="idx7"></a><p class="indatacontent">If you want to migrate to z/OS V1R13
from any other release, contact your IBM representative
to find out if there are alternatives available.</p>
<h2 id="typmste">Typical migration steps</h2>
<p>It is possible to make migration changes at the same time you make
the changes necessary to exploit new functions in the new release.
However, the more prudent approach is to do your migration first and
then exploit new functions. The typical steps to accomplish this are:<a id="idx8"></a><a id="idx9"></a><a id="idx10"></a></p>
<ol type="1">
<li>Learn about z/OS V1R13.
Good sources of information are >z/OS Introduction and Release Guide</a>, >z/OS Planning for Installation</a>,
and <a href="http://www.ibm.com/systems/z/os/zos/">http://www.ibm.com/eserver/zseries/zos/</a>.</li>
<li>Perform as many of the migration actions as you can on your existing
(&quot;old&quot;) system so that you have fewer actions to perform after
you install z/OS V1R13. In
this information, the actions you can perform on your existing system
are identified by headings that say <strong>actions to perform
before installing z/OS V1R13</strong>.
(Note that not all of the actions are required. Some depend on your
environment, configuration, and workload, and are identified accordingly.)
These actions should be made to, or copied (cloned) to, all existing
systems that will be migrated to z/OS V1R13.
<p>Use IBM Health Checker for z/OS to assist with some migration
actions. See <a href="#mighlch">Using IBM Health Checker
for z/OS for migration checking</a>.</p></li>
<li>Order and install coexistence and fallback service for any system
that will share resources with a z/OS V1R13
system.  (See <a href="#coxptfs">Install coexistence and fallback PTFs</a>.) This service needs to be installed
on all systems that will coexist with z/OS V1R13
and all systems that will be migrated to z/OS V1R13 (and which you might fall back to).</li>
<li>Prepare the driving system. For driving system requirements, see
the topic about <a href="../com.ibm.zos.r13.e0zb100/iddsreq.htm">preparing
the driving system</a><a href="../com.ibm.zos.r13.e0zb100/iddsreq.htm">preparing
the driving system</a> in >z/OS Planning for Installation</a>.</li>
<li>Order and install z/OS V1R13.
If you use a ServerPac, refer to <cite>ServerPac: Installing Your Order</cite>. If you use a CBPDO, refer to >z/OS Program Directory</a>.</li>
<li>Prepare target system hardware and software. During this step,
perform the migration actions identified by headings that say <strong>actions to perform before the first IPL of z/OS V1R13</strong>. (Again, not all
of the actions are required. Some depend on your environment, configuration,
and workload, and are identified accordingly.)</li>
<li>IPL the new z/OS V1R13
system with your updated customization and configuration files.</li>
<li>Perform any migration actions identified by headings that say <strong>actions to perform after the first IPL of z/OS V1R13</strong>. (Again, not all
of the actions are required. Some depend on your environment, configuration,
and workload, and are identified accordingly.)
<p>Use IBM Health Checker for z/OS to assist with some migration actions. See <a href="#mighlch">Using IBM Health Checker
for z/OS for migration checking</a>.</p></li>
<li>Deploy z/OS V1R13 to other
systems within a sysplex, data center, and enterprise.
<p><span class="bold-italic">The migration is now complete.</span></p></li>
<li>When you are confident that a system, or in some cases all systems
in a sysplex, are not going to fall back to z/OS V1R12 or z/OS V1R11
exploit the functions introduced in z/OS V1R13.</li>
<li>Deploy this exploitation on other systems (again within a sysplex,
data center, and eventually enterprise).</li></ol>
<h2 id="mighlch">Using IBM Health Checker
for z/OS for migration checking</h2><a id="idx11"></a><a id="idx12"></a><a id="idx13"></a>
<p>Beginning with z/OS V1R10,
the IBM Health Checker for z/OS infrastructure is being exploited
for migration purposes. Checks are being added to help you determine
the applicability of various migration actions. Before you migrate
to your new z/OS release, you
should use these new checks to assist with migration planning. After
you migrate, you should rerun them to verify that the migration actions
were successfully performed. As with any IBM Health
Checker for z/OS check, no
updates are made to the system. These new migration checks only report
on the applicability of specific migration actions on a system, and
only on the currently active system.</p>
<p>The migration checks are very similar to the other checks provided
by IBM Health Checker for z/OS. The only differences are:</p>
<ul>
<li>The names of migration checks follow the convention <strong>ZOSMIGV<var class="pv">vv</var>R<var class="pv">rr_component_program_name</var></strong> (or,
for ICSF, <strong>ICSFMIG<var class="pv">nnnn_component_program_name</var></strong>).
Notice the &quot;MIG&quot; characters followed immediately by the release
identifier. This convention tells you that the check helps with migration
and it tells you the release in which the migration action was introduced. If
the release in which the migration action was introduced is not known,
the name will be ZOSMIGREC.</li>
<li>By default, migration checks are inactive. This is because you
might not want to know about migration actions during nonmigration
periods.</li></ul>
<p id="rexhlth"><strong>System REXX health check considerations</strong></p>
<p>All exploiters of the System REXX support in z/OS require that the System REXX customization
be performed. Using the IBM Health
Checker for z/OS health checks
is one example of possible System REXX exploitation. In particular,
any compiled REXX execs must have the proper runtime support available
from the Alternate Library for REXX (available in z/OS since V1R9) or from the IBM Library for REXX on zSeries (5695-014).   Several IBM Health Checker for z/OS migration health checks have been written in
compiled System REXX.  These health checks rely upon the System REXX
customization and runtime activities being completed.  If System REXX
(and the security environment that System REXX requires) have not
been properly customized, then System REXX health checks will not
execute successfully.</p>
<ul>
<li>For System REXX customization activities, refer to "System REXX"
in >z/OS MVS Programming: Authorized Assembler Services Guide</a>.</li>
<li>For compiled REXX exec runtime availability, see "Alternate Library
for REXX Customization Considerations" in >z/OS Program Directory</a>,
or refer to product documentation accompanying IBM Library for REXX on zSeries.</li></ul>
<p>As stated previously, migration checks are intended to be used
on your current z/OS release
and then again after you have migrated to your new z/OS release. The steps you might follow in each
of these two scenarios are shown below.</p>
<p>On your current z/OS release:</p>
<ol type="1">
<li><em>Install the latest migration checks.</em> Review
all the latest health checks (for both best practices and migration)
by using the functional PSP bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker). If
you want to see all IBM Health
Checker for z/OS checks see <a href="http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html">http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html</a>.
<p>You
might want to install the PTFs during a regular service window so
that an IPL is scheduled afterwards. Checks are often added by a function
when it is started or restarted, so you might find that installing
the PTFs before a scheduled IPL works best for you. Additional migration
checks can be added at different times, so having all the latest ones
installed prior to making your migration plans is recommended.</p></li>
<li><em>Activate the migration checks appropriate to
your migration path.</em> Because the naming convention for migration
checks indicates which release introduced the corresponding migration
actions, you can activate just the checks appropriate for your migration
path. Using SDSF (or another method for viewing checks, such as filters),
you can view ahead of time which migration checks you have available
on your system. For example, if you are migrating from z/OS V1R11 to z/OS V1R13 you need to activate the migration checks
for changes that occurred in both z/OS V1R12
and z/OS V1R13. If you are
migrating from z/OS V1R12 to z/OS V1R13, you only need to activate
the migration checks for changes that occurred in z/OS V1R13. There are many ways to make a check
active, as well as many ways of using wildcards to include specific
checks.  Here are some examples of using the MODIFY command to make
checks active:
<ul>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)</samp></li></ul>Remember that for z/OS,
two naming conventions are used: one for ICSF (that starts with ICSFMIG<var class="pv">nnnn</var>)
and one for the rest of z/OS (that
starts with ZOSMIGV<var class="pv">vv</var>R<var class="pv">rr</var>). Use a wildcard filter
that includes the intended migration checks.</li>
<li><em>Review the migration check output and rerun
checks as appropriate.</em>  Any exceptions should be addressed in
your migration plan.  If you can complete the migration action prior
to moving to the new z/OS release,
you can rerun the check to verify that it was completed correctly
on your current system.</li>
<li><em>Deactivate the migration checks if you desire.</em> 
If you no longer desire to have the migration checks active, you can
deactivate them similar to the way you activated them. For example:
<ul>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)</samp></li></ul></li></ol>
<p>After you have migrated to the new z/OS release,
the steps are similar:</p>
<ol type="1">
<li><em>Install the latest migration checks.</em> 
New migration checks might be available for your new z/OS system since you installed it.  Therefore,
review all the latest health checks (for both best practices and migration)
by using the functional PSP bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker).
If you want to see <strong>all</strong> IBM Health Checker for z/OS checks that are available, see <a href="http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html">http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html</a>.</li>
<li><em>Activate the migration checks appropriate to
your migration path.</em> For migration verification, activate the
checks appropriate on the release you are migrating from, migrating
through, and migrating to. For example, if you are migrating from z/OS V1R11 to z/OS V1R13, you need to activate the migration checks
for changes that occurred in both z/OS V1R12
and z/OS V1R13.  If you are
migrating from z/OS V1R12 to z/OS V1R13, you only need to activate
the migration checks for changes that occurred in z/OS V1R13. Here are some examples of using the
MODIFY command to make checks active. (These are the same activation
commands shown previously.)
<ul>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)</samp></li></ul></li>
<li><em>Review the migration check output and rerun
checks as appropriate.</em>  Any exceptions, which could indicate
that a migration action was not performed correctly, should be addressed.
 Rerun the check after the corrections have been made.</li>
<li><em>Deactivate the migration checks.</em> Once
your migration verification is complete, deactivate the migration
checks similar to the way you activated them. For example (using the
same deactivation commands shown previously):
<ul>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)</samp></li></ul></li></ol>
<p>Within this document, the migration actions that have checks are
clearly identified within the migration actions. All of the checks
are made by IBM Health Checker
for z/OS but, as stated earlier,
some of the checks are the new migration checks (identified by names
that start with ZOSMIGV<var class="pv">vv</var>R<var class="pv">rr</var> or ICSFMIG<var class="pv">nnnn</var>)
and others are regular health checks.</p>
<p>Note that not all migration actions in this document are addressed
by checks; many migration actions do not lend themselves to programmatic
checking. Therefore, use this document to prepare your migration plan
and do not rely solely on checks.</p>
<h2 id="eholdda">EPSPT replaced by FIXCAT and REPORT MISSINGFIX</h2><a id="idx14"></a><a id="idx15"></a><a id="idx16"></a><a id="idx17"></a>
<p>IBM removed the Enhanced
PSP Tool (EPSPT), host compare program, and the associated extract
files from the IBM Technical
Support web site (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
effective 31 December 2010. The Enhanced PSP Tool's function has been
replaced by the addition of FIXCAT (fix category) information to Enhanced
HOLDDATA and the REPORT MISSINGFIX function introduced in z/OS V1R10 SMP/E, which offers
distinct advantages over the Enhanced PSP Tool. This SMP/E function
is also available for all supported releases of z/OS in SMP/E for z/OS V3R6
(5655-G44), which you can order separately.</p><a id="idx18"></a><a id="idx19"></a><a id="idx20"></a><a id="idx21"></a>
<h2 id="zosmfloc">z/OS Management Facility</h2>
<p>IBM z/OS Management Facility (z/OSMF) provides system
programmers with a framework for managing various aspects of a z/OS system through a web browser
interface. By streamlining some traditional tasks and automating others,
z/OSMF can help to simplify the day-to-day operations and administration
of a z/OS system. For more
information about z/OSMF, see <a href="http://www.ibm.com/systems/z/os/zos/zosmf/">www.ibm.com/systems/z/os/zos/zosmf/</a>.</p>
<p>For information about z/OSMF migration steps, see "Migrating from
an earlier release of z/OSMF" in >IBM z/OS Management Facility Configuration Guide</a>.</p>
<h2 id="eafwoma">Elements and features that do not have migration actions</h2><a id="idx22"></a>
<p>The following z/OS V1R13
elements and features do not have migration actions and thus are not
discussed:</p>
<ul>
<li>Alternate Library for REXX<a id="idx23"></a></li>
<li>BDT<a id="idx24"></a></li>
<li>BDT File-to-File<a id="idx25"></a></li>
<li>BDT SNA NJE<a id="idx26"></a></li>
<li>BookManager&reg; BUILD<a id="idx27"></a></li>
<li>BookManager READ<a id="idx28"></a></li>
<li>CIM<a id="idx29"></a></li>
<li>Communications Server Security Level 3<a id="idx30"></a></li>
<li>EREP<a id="idx31"></a></li>
<li>ESCON&reg; Director Support<a id="idx32"></a></li>
<li>FFST<a id="idx33"></a></li>
<li>GDDM<a id="idx34"></a></li>
<li>GDDM-PGF<a id="idx35"></a></li>
<li>GDDM-REXX<a id="idx36"></a></li>
<li>HCD<a id="idx37"></a></li>
<li>HCM<a id="idx38"></a></li>
<li>HLASM<a id="idx39"></a></li>
<li>HLASM Toolkit<a id="idx40"></a></li>
<li>IBM HTTP Server<a id="idx41"></a></li>
<li>ICKDSF<a id="idx42"></a></li>
<li>Integrated Security Services<a id="idx43"></a></li>
<li>Metal C Runtime Library<a id="idx44"></a></li>
<li>MICR/OCR<a id="idx45"></a></li>
<li>NFS<a id="idx46"></a></li>
<li>Run-Time Library Extensions<a id="idx47"></a></li>
<li>TIOC<a id="idx48"></a></li>
<li>z/OS IBM TDS<a id="idx49"></a></li>
<li>z/OS Security Level 3<a id="idx50"></a></li>
<li>3270 PC File Transfer Program<a id="idx51"></a></li></ul>
<h1 id="at1ever">Migration actions for everyone</h1>
<p>This topic describes general migration actions that apply to everyone,
regardless of which elements and features you use.</p><a id="idx52"></a><a id="idx53"></a>
<h2 id="wq14">Migration actions for everyone before installing z/OS V1R13</h2>
<p>This topic describes general migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p><a id="idx54"></a><a id="idx55"></a><a id="idx56"></a><a id="idx57"></a><a id="idx58"></a>
<h3 id="pspbuck">Review PSP buckets</h3>
<p><strong>Description:</strong> You should check the preventive
service planning (PSP) &quot;buckets&quot; for important software and hardware
installation and maintenance information that occurs too late in the
development cycle to be included in the product publications. Included
are PTFs for both service and small programming enhancements (SPEs).<a id="idx59"></a></p>
<table id="wq15" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong>  </p>
<ol type="1">
<li>Identify which PSP buckets to review. For this task you will need
to know:<a id="idx60"></a>
<ul>
<li>PSP bucket upgrade IDs (or &quot;upgrades&quot;). The most relevant
upgrades are those related to z/OS V1R13
and its servers. The z/OS V1R13
upgrade is ZOSV1R13; the server upgrades are shown in <a href="#upgfixc">Table 1</a>.</li>
<li>FIXCAT values if you use the SMP/E REPORT MISSINGFIX command in
conjunction with the FIXCAT type of HOLDDATA (as mentioned in the
tip below). The FIXCAT values are shown in <a href="#upgfixc">Table 1</a>.
Note that the values shown are for the minimum support necessary for
the servers. If you exploit additional functions on a server, the
FIXCAT value will have additional qualifiers.</li></ul>
<table id="upgfixc" width="90%" summary="" border="1" frame="border" rules="all">
<caption>Table 1. PSP bucket upgrades and FIXCAT values for z/OS servers</caption>
<thead valign="bottom">
<tr>
<th id="wq17" width="25%" align="left" valign="bottom">Server</th>
<th id="wq18" width="25%" align="left" valign="bottom">Upgrade</th>
<th id="wq19" width="50%" align="left" valign="bottom">FIXCAT value</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq17">IBM zEnterprise zEC12</td>
<td headers="wq18">2827DEVICE</td>
<td headers="wq19">IBM.Device.Server.zEC12-2827</td>
</tr>
<tr>
<td headers="wq17">z196</td>
<td headers="wq18">2817DEVICE</td>
<td headers="wq19">IBM.Device.Server.z196-2817</td>
</tr>
<tr>
<td headers="wq17">z114</td>
<td headers="wq18">2818DEVICE</td>
<td headers="wq19">IBM.Device.Server.z114-2818</td>
</tr>
<tr>
<td headers="wq17">z10&trade; EC</td>
<td headers="wq18">2097DEVICE</td>
<td headers="wq19">IBM.Device.Server.z10-EC-2097</td>
</tr>
<tr>
<td headers="wq17">z10 BC</td>
<td headers="wq18">2098DEVICE</td>
<td headers="wq19">IBM.Device.Server.z10-BC-2098</td>
</tr>
<tr>
<td headers="wq17">z9 EC</td>
<td headers="wq18">2094DEVICE</td>
<td headers="wq19">IBM.Device.Server.z9-EC-2094</td>
</tr>
<tr>
<td headers="wq17">z9 BC</td>
<td headers="wq18">2096DEVICE</td>
<td headers="wq19">IBM.Device.Server.z9-BC-2096</td>
</tr>
<tr>
<td headers="wq17">z990</td>
<td headers="wq18">2084DEVICE</td>
<td headers="wq19">IBM.Device.Server.z990-2084</td>
</tr>
<tr>
<td headers="wq17">z890</td>
<td headers="wq18">2086DEVICE</td>
<td headers="wq19">IBM.Device.Server.z890-2086</td>
</tr>
<tr>
<td headers="wq17">z900</td>
<td headers="wq18">2064DEVICE</td>
<td headers="wq19">IBM.Device.Server.z900-2064</td>
</tr>
<tr>
<td headers="wq17">z800</td>
<td headers="wq18">2066DEVICE</td>
<td headers="wq19">IBM.Device.Server.z800-2066</td>
</tr>
</tbody>
</table></li>
<li>Obtain the PSP buckets from <a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a> or
from IBMLink.<a id="idx61"></a><a id="idx62"></a><a id="idx63"></a></li>
<li>Review the PSP buckets and take whatever actions are prescribed.</li></ol>
<p><strong>Tip:</strong> To simplify finding the appropriate
PSP bucket and identifying which PTFs listed in the PSP bucket need
to be installed on your system, you can use SMP/E FIXCATs and the
REPORT MISSINGFIX command. (The FIXCAT values are shown in <a href="#upgfixc">Table 1</a>.)</p>
<p><strong>Reference information:</strong></p>
<ul>
<li> For z/OS subsets, see >z/OS Program Directory</a>.</li>
<li>For details about the SMP/E REPORT MISSINGFIX command, see >SMP/E Commands</a>.</li></ul>
<h3 id="coxptfs">Install coexistence and fallback PTFs</h3>
<p><strong>Description:</strong> Coexistence and fallback PTFs
installed on pre-z/OS V1R13 systems allow those systems to
coexist with z/OS V1R13 systems
during your migration, and allow backout from z/OS V1R13 to the previous systems if necessary.
Coexistence and fallback are important because they allow you to migrate
systems in a multisystem configuration to z/OS V1R13 using rolling IPLs (one system at a time),
allowing for continuous application availability.</p><a id="idx64"></a>
<table id="wq20" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Install the appropriate PTFs.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Before introducing z/OS V1R13 into your environment,
install coexistence and fallback PTFs on all pre-z/OS V1R13
systems with which your z/OS V1R13
system will coexist.</p>
<p> Use the SMP/E REPORT MISSINGFIX command in conjunction with the
FIXCAT type of HOLDDATA as follows:</p>
<ol type="1">
<li>Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS
V1R13 systems. Use your normal service acquisition portals or download
the HOLDDATA directly from  <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure that you select <strong>Full</strong> from the Download
NOW column to receive the FIXCAT HOLDDATA, as the other files do not
contain FIXCATs.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS
V1R13 systems and specify a Fix Category (FIXCAT) value of &quot;IBM.Coexistence.z/OS.V1R13&quot;.
The report will identify any missing coexistence and fallback PTFs
for that system. For complete information about the REPORT MISSINGFIX
command, see >SMP/E Commands</a>.</li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
coexistence and fallback PTFs.</li></ol>
<p><strong>Reference information:</strong> For an explanation
of the z/OS coexistence-migration-fallback
policy, see the <a href="../com.ibm.zos.r13.e0zb100/tolco.htm">coexistence and fallback</a> topic
in >z/OS Planning for Installation</a>.</p>
<h3 id="at3sofc">Use zSoftCap to identify the effect of capacity changes</h3>
<p><strong>Description:</strong> The zSoftware Migration Capacity
Planning Aid (zSoftCap) is a PC-based tool that evaluates the effects
of  software release migrations. <a id="idx65"></a><a id="idx66"></a><a id="idx67"></a><a id="idx68"></a><a id="idx69"></a></p>
<table id="wq22" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to help in assessing processor
capacity and available resources when migrating to new software levels.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>This tool runs on your workstation. Requirements
are: 
<ul>
<li>A dual-core technology, or faster, processor.</li>
<li>An SVGA display 1024 x 768 or better.</li>
<li>Approximately 5 MB of hard disk space for the zSoftCap application
and user's guide, plus 80 MB for the IBM Java 1.6 runtime environment.</li></ul></td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>This tool runs on your workstation. Requirements
are:
<ul>
<li>Windows 7 or Windows XP.</li>
<li>IBM Java <span>1.6</span>, or later, runtime environment.
This environment is available with the tool.</li></ul></td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Download zSoftCap from one of the following web sites:<a id="idx70"></a><a id="idx71"></a><a id="idx72"></a>
<ul>
<li>Customers: <a href="http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS268">http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS268</a>.</li>
<li>Business partners: <a href="http://partners.boulder.ibm.com/src/atsmastr.nsf/Web/Techdocs">http://partners.boulder.ibm.com/src/atsmastr.nsf/Web/Techdocs</a>.
Note that this requires an ID on PartnerWorld&reg;.</li></ul></li>
<li>Run zSoftCap to determine your expected increase in CPU utilization
(if any) and to identify your storage requirements, such as how much
storage is needed to IPL.</li></ul>
<p><strong>Reference information:</strong> <cite>zSoftCap User's Guide</cite>, which is provided with the tool.</p>
<h3 id="dcegone">Stop using Computing Environment (DCE) and DCE Security Server</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, the Distributed Computing Environment
(DCE) and DCE Security Server elements of z/OS will no longer be shipped. Any product or application
with direct or indirect dependency on either of these DCE elements
of z/OS needs to be migrated
to another solution.  </p>
<ul>
<li><a id="idx73"></a><a id="idx74"></a>DCE includes the following interfaces that other products or applications
depend on: 
<ul>
<li>DCE RPC (DCE Remote Procedure Call)</li>
<li>CDS (DCE Cell Directory Service)</li>
<li>DTS (DCE Distributed Time Service)</li>
<li>DCE Threads Service</li>
<li>IDL (Interface Definition Language - part of RPC, but widely
used)</li></ul></li>
<li><a id="idx75"></a>Other products known to depend on DCE interfaces include the following: 
<ul>
<li>The DCE Security Server</li>
<li>DFS (Distributed File Service)</li>
<li>DCE Application Support Server (no longer supported; used IDL
and RPC Runtime to interface with back ends like CICS&reg;, IMS&trade;,
OTMA, etc.)</li></ul></li></ul>
<table id="wq23" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(previewed in z/OS V1R12 Software
Announcement 210-235, dated July 22, 2010).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGREC_SMB_RPC available in APAR OA30117.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Look for:  
<ul>
<li>DCEKERN started task is necessary for your product or application
to work, or</li>
<li>DCE API function calls are made by your product or application,
including calls to the RPC Runtime.</li></ul></li>
<li>Then migrate: 
<ul>
<li>All dependencies on any DCE technology to an equivalent offering
from another product (IBM WebSphere&reg; Application Server,
the IBM Network Authentication
Service, or the IBM Directory
Server). For more information, see the Redbooks&reg; <em>DCE Replacement Strategies</em> at <a href="http://www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf">http://www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf.</a>.</li></ul></li></ul>
<p><strong>Deleting DCE-related userids</strong>: The
DCE-related userids are safe to delete, if you are not using
DCE on a lower level z/OS system
that shares the same security (RACF)
database, or on some other system in the RRSF network if the automatic
command direction for those ids is active for the USER class. This
condition applies to any STARTED profile.  Note that Distributed File
Service Server Message Block (SMB) or another product might be using
the DCE segment defined in the security (RACF) database so you should not remove that segment,
unless you are sure it is not being using by any service or product.</p>
<p><strong>Considerations for a RACF userid that was associated with the DCEKERN
address space</strong>: In previous releases of z/OS, you needed to ensure that the following conditions
were in effect for the z/OS user
ID under which DCE was to be started:</p>
<ul>
<li>A DCE segment did not exist for that user in the RACF profile.</li>
<li>The AUTOLOGIN variable in the DCE segment was set to NO.</li></ul><p class="indatacontent">This was necessary whether the server was started by batch job
or by a procedure. Configuring the user ID differently could have
produced unpredictable results when the server was started.</p>
<p>In this release, you can eliminate the RACF userid associated with DCEKERN if the userid
is not used for any other purpose. Also, check to determine if the
userid had any DCE daemons running in an address space other than
that of the main DCEKERN (for example, the DCE Security Server address
space if it was run in a separate job). You can most likely eliminate
the user under which the DCE Security Server runs as long as it is
not used for any other purpose.</p>
<p><strong>Considerations for a RACF userid that was associated with the DCECONF
utility</strong>: You can also eliminate the userid that executed the
DCECONF (configuration) utility as long as that userid is not used
for any other purpose. (The administrator of the DCECONF utility was
probably given a superuser ID. In z/OS UNIX system Services, the superuser
or root has a user identifier (UID) of zero (0). A user can be given
superuser privileges by specifying zero in the UID parameter of the
ADDUSER or ALTUSER commands. Before this release, the DCECONF administrator
required update authority to the DCEKERN.START.REQUEST Security Facility.
This facility was created during the installation of z/OS DCE and determined if a TSO user had the necessary
permissions to start or stop the z/OS DCE
daemons in the DCEKERN address space. For information, see <cite></cite>.)</p>
<p><strong>Considerations for RACF users
that were created by DCE interoperability</strong>: DCE also provided
a mechanism to allow for single signon/interoperability tto map a
DCE user (principal) with a RACF user
and create a DCE segment for the RACF user.
This interoperability information was defined in the DCE segment in RACF so you can look for any RACF users with a DCE segment.
Check those DCE segments to see if they might have another function
other than that for DCE. If not, you can delete those RACF users.</p>
<p><strong>Reference information:</strong> Redbooks <em>DCE Replacement Strategies</em> at <a href="http://www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf">http://www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf.</a>.</p><a id="idx76"></a><a id="idx77"></a><a id="idx78"></a><a id="idx79"></a>
<h3 id="zrodasd">Add or change volumes to keep your z/OS root file system in a single data set</h3>
<p><strong>Description:</strong> Because of release enhancements
and service, the size of the z/OS root
file system (or &quot;version root file system&quot;) continues to grow
from release to release. As of z/OS V1R10,
the size of the z/OS root file
system, whether HFS or zFS, was approximately 3100 cylinders on a
3390 Direct Access Storage Device. This is close to the limit of 3339
cylinders on a 3390-3 device.<a id="idx80"></a><a id="idx81"></a><a id="idx82"></a></p>
<p>It is advisable to have the z/OS root
file system within a single data set for ease of management.</p>
<table id="wq24" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended for ease of management if
your z/OS root file system
resides on a 3390-3 volume (or another DASD volume that is close to
the 3390-3 limit of 3339 cylinders).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use IBM Health
Checker for z/OS check CHECK(IBMUSS,
ZOSMIGREC_ROOT_FS_SIZE) to determine if a volume has enough space
for the z/OS root file system. This
capability is available in z/OS V1R11
with PTF UA49363 (APAR OA28684) installed.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To keep the z/OS root file system in a single data set, do one
of the following:</p>
<ul>
<li>Move your z/OS root file
system to a larger DASD volume geometry.</li>
<li>Use multiple volumes for the z/OS root
file system data set.</li></ul>
<p>If your z/OS root data set
cannot fit on the volume or volumes you have defined for it, divide
the z/OS root, with the smaller
file systems being managed together.</p>
<p>Remember that all systems to which you deploy the z/OS root file system need sufficient DASD space
to hold the z/OS root.</p>
<p>Beginning with z/OS V1R11
ServerPac, the default device type is changed to 3390-9 instead of
3390-3 in the Modify System Layout panels.</p>
<p><strong>Tip:</strong> </p>
<ul>
<li>File systems for subsystems and products other than the z/OS product itself might also
increase in size. When examining the volume for how much space your z/OS file system is using, check
other product file system sizes too.</li></ul>
<p><strong>Reference information:</strong> For more information
about multivolume data sets, see >z/OS DFSMS Implementing System-Managed Storage</a>.</p><a id="idx83"></a>
<h3 id="vxcfgps">Verify that you have enough XCF groups in your CDS and enough
XCF members in your XCF groups</h3>
<p><strong>Description:</strong> Over time, as various z/OS functions and applications
exploit XCF services, you must ensure that there is enough space in
the sysplex couple data set for all the XCF groups and members that
are to be defined by the exploiters. It is possible that your sysplex
couple data set could contain an inadequate number of XCF groups or
members.</p>
<div>
<div class="notetitle" id="wq25">Note:</div>
<div class="notebody">Starting with z/OS V1R13,
 JES2 is using new XCF groups for its spool migration enhancement.
JES spool migration utilizes tasks on all members of a MAS to manage
the migration of a spool volume's data and the access to that migrating
or migrated data. These various tasks communicate using messages sent
through JESXCF services. The JESXCF services utilize one XCF group
for each active migration to identify what messages are for which
active migration. XCF groups are a limited system resource, so JES2
limits the number of concurrent active migrations to five. If you
plan to  perform spool migrations, verify that you have up to five
XCF groups available if  you intend to have up to five spool migrations
active at any given time. JES2 will only utilize the number of XCF
groups available, up to five, for spool migrations.</div></div>
<table id="wq26" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that you have
an adequate number of XCF groups and members formatted in your sysplex
couple data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use IBM Health
Checker for z/OS check XCF_SYSPLEX_CDS_CAPACITY,
which checks the adequacy of the number of groups, members, and systems
for which a sysplex CDS is formatted.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Issue the DISPLAY XCF,COUPLE command on your current system. Notice
the values of MAXGROUP and PEAK for your sysplex couple data sets.
These values show you the maximum number of XCF groups that the couple
data sets can support, and the peak number of XCF groups ever in use
in the sysplex. Also notice the values of MAXMEMBER and PEAK for your
sysplex couple data sets. These values show you the maximum number
of members that the couple data set can support in one group, and
the greatest number of members ever in use in the largest group in
the sysplex.</li>
<li>If your peak member value is close to the maximum member value,
you might want to reformat your sysplex couple data sets to support
a larger maximum number of members to be used by any one group.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For information about formatting sysplex couple data sets with
the MAXGROUP and MAXMEMBER parameters, see >z/OS MVS Setting Up a Sysplex</a>.</li>
<li>For information about the DISPLAY XCF command, see >z/OS MVS System Commands</a>.</li></ul>
<h3 id="msysset">Stop using Managed System Infrastructure for Setup (msys for
Setup) element</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, support is withdrawn for Managed System
Infrastructure for Setup (msys for Setup). In the future, IBM intends to continue to deliver
improvements to help with z/OS setup
and configuration.<a id="idx84"></a></p>
<table id="wq28" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>zOS V1R12 (previewed in Announcement Letter
Number AP05-1215 dated July 27, 2005).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use msys for Setup.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Discontinue using msys for
Setup for function enablement, setup, or configuration of z/OS.</p>
<p><strong>Reference information:</strong> For software supported
with z/OS, see the <a href="../com.ibm.zos.r13.e0zb100/pgmreqs.htm">software requirements</a> topic
in >z/OS Planning for Installation</a>.</p>
<h3 id="at3uw9c">Upgrade Windows 2000,
98, 95, and NT clients</h3>
<p><strong>Description:</strong> z/OS does
not support service for client operating systems whose service is
withdrawn by the operating system manufacturer. As a result, IBM no longer supports service for
clients running Windows 2000, Windows 98, Windows 95, or Windows NT Workstation 4.xx.<a id="idx85"></a></p>
<table id="wq29" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>13 August 2002 in the z/OS V1R4 availability announcement.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because z/OS does not support service for client operating
systems whose service is withdrawn by the operating system manufacturer.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use a supported follow-on
to Windows 2000, Windows 98, Windows 95, or Windows
NT Workstation 4.xx.</p>
<p><strong>Reference information:</strong> For client software
supported with z/OS, see the <a href="../com.ibm.zos.r13.e0zb100/pgmreqs.htm">software requirements</a> topic
in >z/OS Planning for Installation</a>.</p>
<h2 id="wq30">Migration actions for everyone before the first IPL of z/OS V1R13</h2>
<p>This topic describes general migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx86"></a><a id="idx87"></a><a id="idx88"></a><a id="idx89"></a><a id="idx90"></a><a id="idx91"></a><a id="idx92"></a>
<h3 id="at3gena">Set up an IPCS environment</h3>
<p><strong>Description:</strong> The interactive problem control
system (IPCS) is a tool in the BCP that provides formatting and analysis
support for dumps and traces. You must set up an IPCS environment
so that you can process any dumps taken on the newly-built z/OS system.</p>
<div>
<div class="notetitle" id="wq31">Note:</div>
<div class="notebody"></div></div><a id="idx93"></a>
<table id="wq32" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the target system cannot be used for
native IPCS and usage of IPCS for information produced by the target
system is necessary.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td>
<p><strong>Target system software requirements:</strong></p></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>The version and release level of IPCS must match
the level of the system that produced the dump. You must use the z/OS MVS&trade; libraries
of IPCS code, for example, to analyze a dump or trace produced by
an z/OS MVS system. 
<p><strong>Tip:</strong> If it is
necessary to have unique IPCS data set names for your current system
(because you already have the IPCS data sets with similar names on
your earlier system), you can create a unique alias in your catalog
that resolves to the current IPCS data sets. This will allow you to
have &quot;duplicately&quot;-named IPCS data sets, which are uniquely
referenced.</p>
<p>When using unique aliases, remember that you may
have to update the security definition for the unique high-level qualifier
used in the catalog.</p></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Set up an IPCS environment.
For guidance, use the information listed in &quot;Reference information&quot; below.
During setup, ensure that your logon procedure points to the target
system's level of IPCS data sets, which are shown in <a href="#ipcsdsc">Table 2</a>.</p>
<p></p>
<div>
<div class="notetitle" id="wq33">Note:</div>
<div class="notebody">z/OS V1R13
GTF data cannot be properly formatted on a pre-z/OS V1R13 system.
If you attempt to format z/OS V1R13
GTF data with IPCS on a pre-z/OS V1R13 system, the fields will be
unusable. Also note that pre-z/OS V1R13 GTF data cannot be properly
formatted on a z/OS V1R13 system.
You must use z/OS V1R13 IPCS
for z/OS V1R13 GTF data and
pre-z/OS V1R13 IPCS for pre-z/OS V1R13 GTF data. You cannot merge
pre-z/OS V1R13 GTF data with z/OS V1R13
GTF data and expect to format it on any z/OS release.
Plan on using the IPCS level associated with the GTF data that you
collect.</div></div>
<table id="ipcsdsc" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 2. IPCS data set requirements for a logon procedure or DD name allocation</caption>
<thead valign="bottom">
<tr>
<th id="wq34" align="left" valign="bottom">DD name</th>
<th id="wq35" align="left" valign="bottom">Data set name</th>
<th id="wq36" align="left" valign="bottom">Notes&reg;</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq34">IATTABL</td>
<td headers="wq35">SYS1.SIATTBL0, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td rowspan="3" headers="wq34">IPCSPARM
<p></p>
<div>
<div class="notetitle" id="wq37">Note:</div>
<div class="notebody">This
DD name is needed if one of the following is true:
<ul>
<li>z/OS V1R13 GTF data cannot
be properly formatted on a pre-z/OS V1R13 system. If you attempt to
format z/OS V1R13 GTF data
with IPCS on a pre-z/OS V1R13 system, the fields will be unusable.
Conversely, pre-z/OS V1R13 GTF data cannot be properly formatted on
a z/OS V1R13 system. You must
use z/OS V1R13 IPCS for z/OS V1R13 GTF data and pre-z/OS
V1R13 IPCS for pre-z/OS V1R13 GTF data. You cannot merge pre-z/OS
V1R13 GTF data with z/OS V1R13
GTF data and expect to format it on any z/OS release.
Plan on using the IPCS level associated with the GTF data that you
collect.</li>
<li>The system on which the dump was taken has different BCP and JES
levels than the system on which the dump will be examined using IPCS.</li>
<li>You have not specified these data sets in your system's parmlib
concatenation.</li></ul></div></div></td>
<td headers="wq35">SYS1.PARMLIB</td>
<td headers="wq36"><a id="idx94"></a><a id="idx95"></a>This is the data set that contains all the shipped z/OS V1R13 parmlib IPCS members.
If the copies of BLSCECT and all the other IPCS members are not at z/OS V1R13 level, then IPCS might
fail when you attempt to use it.</td>
</tr>
<tr>
<td headers="wq35">SYS1.SHASPARM, if applicable</td>
<td headers="wq36">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq35">SYS1.SIATPARM, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td rowspan="2" headers="wq34">ISPMLIB</td>
<td headers="wq35">SYS1.SBLSMSG0</td>
<td headers="wq36"></td>
</tr>
<tr>
<td headers="wq35">SYS1.SIATMSG0, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td rowspan="3" headers="wq34">ISPPLIB</td>
<td headers="wq35">SYS1.SBLSPNL0</td>
<td headers="wq36"></td>
</tr>
<tr>
<td headers="wq35">SYS1.SHASPNL0, if applicable</td>
<td headers="wq36">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq35">SYS1.SIATPNL0, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq34">ISPSLIB</td>
<td headers="wq35">SYS1.SBLSKEL0</td>
<td headers="wq36"></td>
</tr>
<tr>
<td headers="wq34">ISPTLIB</td>
<td headers="wq35">SYS1.SBLSTBL0</td>
<td headers="wq36"></td>
</tr>
<tr>
<td rowspan="4" headers="wq34">STEPLIB
<p></p>
<div>
<div class="notetitle" id="wq38">Note:</div>
<div class="notebody">This
DD name is needed if the system on which the dump was taken has different
BCP and JES levels than the system on which the dump will be examined
using IPCS.</div></div></td>
<td headers="wq35">SYS1.MIGLIB</td>
<td headers="wq36"></td>
</tr>
<tr>
<td headers="wq35">SYS1.SIEAMIGE</td>
<td headers="wq36">This data set was added in z/OS V1R7. It is a PDSE data set that complements
SYS1.MIGLIB. This data set is used along with SYS1.MIGLIB for IPCS.</td>
</tr>
<tr>
<td headers="wq35">SYS1.SHASMIG, if applicable</td>
<td headers="wq36">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13</td>
</tr>
<tr>
<td headers="wq35">SYS1.SIATMIG, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13</td>
</tr>
<tr>
<td headers="wq34">SYSEXEC</td>
<td headers="wq35">SYS1.SIATCLI0, if applicable</td>
<td headers="wq36">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13</td>
</tr>
<tr>
<td headers="wq34">SYSPROC</td>
<td headers="wq35">SYS1.SBLSCLI0</td>
<td headers="wq36"></td>
</tr>
</tbody>
</table>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about IPCS, see >z/OS MVS IPCS Customization</a>.</li>
<li>For more information about the correct logon procedure updates,
see the >z/OS Program Directory</a>.</li>
<li>For information about setting up the JES2 IPCS environment, see >z/OS JES2 Diagnosis</a>.</li>
<li>For information about setting up the JES3 IPCS environment, see >z/OS JES3 Diagnosis</a>.</li>
<li>For information about running different levels of IPCS, see "Running
Different Levels of IPCS " in <cite></cite>.</li>
<li> For additional information, see >z/OS Communications Server: IP Diagnosis Guide</a>.</li></ul>
<h3 id="at3genb">Use IBM-supplied parmlib and proclib members</h3>
<p><strong>Description:</strong> Ensure that all new and changed
parmlib and proclib members that are shipped in z/OS V1R13 are updated in your parmlib and proclib
concatenations.<a id="idx96"></a><a id="idx97"></a><a id="idx98"></a><a id="idx99"></a></p>
<table id="wq39" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>For parmlib, add the data set pointed to by the z/OS V1R13 PARMLIB DDDEF to your parmlib concatenation.
The data set should generally be added last in the concatenation,
and you should make sure that the other data sets in the concatenation
do not have members with the same names as IBM-supplied members. If
you place the data set on the system residence volume and use an indirect
catalog entry, future migrations will not require this particular
migration step.</li>
<li>For proclib:
<ol type="1">
<li>Ensure that the default proclib members have been copied to your
default proclib to pick up the new and changed members.</li>
<li>Update individual sample members provided and ensure they are
accessible to the system, as shown in the table of proclib member
updates in >z/OS Program Directory</a>.</li>
<li>Ensure that the procedure libraries listed in the table of libraries
to be added to the proclib concatenation in >z/OS Program Directory</a> have
been placed in the necessary procedure library concatenations and
are available to the system.</li></ol></li></ul>
<p><strong>Reference information:</strong> For lists of parmlib
and proclib members that are shipped, see >z/OS Program Directory</a>.</p>
<h3 id="at3gend">Migrate /etc and /var system control files</h3>
<p><strong>Description:</strong> The <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> directories
contain system control files. <a id="idx100"></a><a id="idx101"></a>The <samp class="xph">/etc</samp> directory contains customization
data that you maintain and the <samp class="xph">/var</samp> directory contains
customization data that IBM maintains.</p>
<p> The following elements and features use <samp class="xph">/etc</samp>: </p>
<ul>
<li>BCP (Predictive Failure Analysis). See <a href="#pfaparm">Provide the <var class="pv">migrate</var> or <var class="pv">new</var> parameter
when running the PFA install script</a>.</li>
<li>CIM.</li>
<li>Communications Server (IP Services component). See <a href="#upcsetc">IP Services: Update /etc configuration files</a>.</li>
<li>Cryptographic Services (PKI Services and System SSL components).</li>
<li>DFSMSrmm.</li>
<li>Distributed File Service. The SMB server uses <samp class="xph">/etc/dfs</samp>.</li>
<li>IBM HTTP Server.</li>
<li>z/OS IBM TDS (LDAP server component) <samp class="xph">uses
/etc/ldap</samp>.</li>
<li>Infoprint Server. See <a href="#ai3svco">Remount the Printer Inventory and copy files that were customized</a>.</li>
<li>Library Server. See <a href="#libsb1i">Library Server actions to perform before the first IPL of z/OS V1R13</a>.</li>
<li>z/OS UNIX.</li></ul>
<p> The following elements and features use <samp class="xph">/var</samp>: </p>
<ul>
<li>Cryptographic Services (OCSF component). See <a href="#ae3ois">OCSF: Migrate the directory structure</a>.</li>
<li>DFSMSrmm.</li>
<li>z/OS IBM TDS (LDAP server component) uses <samp class="xph">/var/ldap</samp>.</li>
<li>Infoprint Server. See <a href="#ai3svco">Remount the Printer Inventory and copy files that were customized</a>.</li>
<li>Integrated Security Services. The Network Authentication Service
component uses <samp class="xph">/var/skrb</samp>.</li></ul>
<p>During installation, subdirectories of <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> are
created. If you install z/OS using
ServerPac or SystemPac&reg;,
some files are loaded into <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> because
of the customization performed in ServerPac and SystemPac. You have to merge the files in <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> with
those on your previous system. If you install z/OS using CBPDO, you should copy the files from
your old system to the z/OS V1R13 <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> subdirectories.</p>
<p>After merging or copying the contents of <samp class="xph">/etc</samp> and <samp class="xph">/var</samp>,
you have to inspect and modify the files as necessary to reflect z/OS V1R13 requirements.</p>
<table id="wq41" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Copy files from your old system
to the z/OS V1R13 <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> subdirectories,
and then modify the files as necessary to reflect z/OS V1R13 requirements. If you have other files
under your existing <samp class="xph">/var</samp> directory, then you will have
to merge the old and new files under <samp class="xph">/var</samp>. The easiest
way to do this is to create a clone of your current <samp class="xph">/var</samp> file
system and then copy the new <samp class="xph">/var</samp> files into the clone.</p>
<p>Many z/OS UNIX utilities are available for comparing and copying
directory structures and files. Two that are especially helpful for <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> migration
work are: </p>
<ul>
<li><strong>diff</strong> (with the <strong>-r</strong> option,
for recursion): This utility is very useful for comparing the path
structures and file contents, and has many options available. The <strong>dircmp</strong> utility has fewer options for directory comparisons,
and the <strong>cmp</strong> utility stops after the first difference
in a file comparison and has output that is more cumbersome.</li>
<li><strong>pax</strong>: The <strong>-rw</strong> option
works like a copy (instead of making or extracting from a single file
archive) for directories, symbolic links, and files. Consider the <strong>-pe</strong> option for saving the attributes when doing
the copy. The <strong>-k</strong> option prevents overwriting
of existing files.</li></ul>
<p>To determine what you need to migrate, first compare the ServerPac's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems with your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. Mount a copy of your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems to a location outside the ServerPac file system. For instance,
you might have your ServerPac file systems at <samp class="xph">/ServerPac/zOS_Rx/etc</samp> and <samp class="xph">/ServerPac/zOS_Rx/var</samp>,
and your existing file systems at <samp class="xph">/Service/ImageX/etc</samp> and <samp class="xph">/Service/ImageX/var</samp>.
You might have several file systems to mount that are copies of each
of your image's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file systems (ImageX,
ImageY, and ImageZ, for instance). To compare the ServerPac and existing
system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp>, you can run two z/OS UNIX commands,
such as: </p>
<pre class="xmp"><code>diff  -r  /ServerPac/zOS_Rx/etc  /Service/ImageX/etc
diff  -r  /ServerPac/zOS_Rx/var  /Service/ImageX/var</code></pre><p class="indatacontent">These command
results will give you a list of the changes that your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems are missing--both the structure differences and the file
content differences.</p>
<p>Once you know the directories, symbolic links, and files you are
missing from your existing system, there are several ways to propagate
the ServerPac information forward: </p>
<ul>
<li>You could use the <strong>pax</strong> command (with the <strong>-k</strong> option) to copy from the ServerPac <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems to each of your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. For example:
<pre class="xmp"><code>cd /ServerPac/zOS_Rx/etc
pax -rvwk -pe * /Service/ImageX/etc</code></pre>Another example:
<pre class="xmp"><code>cd /ServerPac/zOS_Rx/var
pax -rvwk -pe * /Service/ImageX/var</code></pre>The <strong>pax</strong> command
is a good choice because it copies all files, directories, and symbolic
links for each file system from the ServerPac system using a single
command without overlaying any existing files.</li>
<li>You could rerun the product-supplied MKDIR jobs to recreate the
directories and symbolic links on each of your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. (A list of the MKDIR jobs is found in >z/OS Program Directory</a> and
the other program directories for the products that were in your ServerPac
order.) MKDIR jobs are designed to be run multiple times without damaging
your existing file system. For the files under <samp class="xph">/var/ocsf</samp>,
rerun the OCSF-supplied <samp class="xph">ocsf_install_crypto</samp> installation
script. Or, you can combine these jobs and script them into a single
batch job to make the execution more consolidated and repeatable.</li></ul>
<p>After you have made the changes to a copy of your existing image's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems, you can unmount them and use them for your deployment of
the ServerPac system, as your schedule indicates. Remember, you are
using <em>copies</em> of your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems, and you are <em>preserving</em> what you had
previously by modifying copies, so your customization for those specific
existing images is not lost.</p>
<p><strong>Reference information:</strong> None.</p>
<h3 id="automsg">Update automation and procedures for changed and deleted messages</h3>
<p><strong>Description:</strong> Every release, many messages
change and some are deleted. If you use automation programs to handle
messages, or you have operator or other procedures that deal with
messages, you should update the programs or procedures appropriately.</p><a id="idx102"></a>
<table id="wq42" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review the lists of changed
and deleted messages at <a href="../com.ibm.zos.r13.e0zh300/msgchg.htm">Summary
of message changes</a> in >z/OS Summary of Message and Interface Changes</a>.
Update programs that automate on these messages and make other necessary
accommodations.</p>
<p>Also, see the following migration actions, which have greater detail
about some of the message changes:</p>
<ul>
<li><a href="#ief37smf">Update automation that handles messages IEF374I and IEF376I</a></li>
<li><a href="#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></li>
<li><a href="#dfsomsg">Update automation for changed DFSORT messages</a></li>
<li><a href="#btemode">Migrate from IP PrintWay basic
mode to extended mode</a></li>
<li><a href="#dlogsplit">Modify code that depends on the format of suppressed split
messages in the DLOG</a></li></ul>
<p><strong>Reference information:</strong> For a list of changed
and deleted messages, see >z/OS Summary of Message and Interface Changes</a>.</p>
<h3 id="at3geng">Rework and install user modifications</h3>
<p><strong>Description:</strong> A user modification is a change
constructed by a user to modify an existing function, add to an existing
function, or add a user-defined function. <a id="idx103"></a><a id="idx104"></a><a id="idx105"></a><a id="idx106"></a><a id="idx107"></a><a id="idx108"></a>Common types of user modifications
are: </p>
<ul>
<li>User-written and vendor-written exit routines.</li>
<li>User-written and vendor-written SVCs.</li>
<li>User-written and vendor-written termination routines.</li>
<li>Modifications of IBM source
code.</li>
<li>Unit information modules (UIMs) for non-IBM hardware.</li>
<li>User-written and vendor-written modules that are listed in a NUCLST<var class="pv">xx</var> parmlib
member.</li>
<li>Updates to default modules to set site defaults differently than
the IBM-supplied defaults, such as for the following element and features:
<ul>
<li>C/C++ without Debug Tool.</li>
<li>DFSORT.
Consider using ICEPRM<var class="pv">xx</var> parmlib members, introduced in z/OS V1R10, to eliminate the assembler
language installation option modules.</li>
<li>HLASM.</li>
<li>ISPF (specifically, the ISPF configuration table).</li>
<li>Language Environment&reg;.
Consider using the CEEROPT module, which can be used to specify runtime
options for CICS, IMS LRR, and other LRR users. Also
consider using the CEEPRM<var class="pv">xx</var> parmlib member, introduced in z/OS V1R7, to eliminate the assembler
language runtime option modules. As of the next release of z/OS there is no longer any support
for the SMP/E USERMOD for customizing the LE Run-time options.</li>
<li>SDSF (ISFPARMS customization). See <a href="#ax3assm">Use dynamic statements for ISFPARMS to avoid reassembly</a> for
further information.</li></ul></li></ul>
<p>If you made any user modifications, you have to determine which
ones need to be reworked and which ones just need to be reinstalled.</p>
<table id="wq43" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you made any user modifications.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use the z/OS SMP/E Planning and Migration Assistant to help
determine which user modifications need to be reworked and which just
have to be reinstalled. The Top or New Intermediate Product Migration
Changes Report uses data found on your system, combined with IBM-supplied
information from the Software Information Base, to show you the current
levels of products available as well as product migration and functional
changes using a comparison of FMIDs. You can use this report to determine
the product migration impacts by reviewing the &quot;changed&quot; FMIDs.
This can help you assess how many user modifications have to be reworked
if you issued the LIST SYSMOD USERMOD FORFMID (listing the &quot;changed&quot; FMIDs)
command. All other user modifications can be reinstalled without having
to be reworked.</p>
<div>
<div class="notetitle" id="wq44">Note:</div>
<div class="notebody">IBM recommends
using exit routines for any user modifications where possible, and
installing the exit routines with SMP/E. By using SMP/E, it is easier
to bring forward modifications to the z/OS release
you are installing.</div></div>
<p><strong>Reference information:</strong></p>
<ul>
<li>For information about SDSF customization, see >z/OS SDSF Operation and Customization</a>.</li>
<li>For information about XL C/C++ customization, see .</li>
<li>For information about DFSORT customization, see >z/OS DFSORT Installation and Customization</a>.</li>
<li>For information about HLASM customization, see >HLASM Installation and Customization Guide</a>.</li>
<li>For information about ISPF customization, see >z/OS ISPF Planning and Customizing</a>.</li>
<li>For information about Language Environment customization, see >z/OS Language Environment Customization</a>.</li></ul>
<h3 id="at3genh">Reconnect non-IBM products</h3>
<p><strong>Description:</strong> If you use any independent software
vendor (ISV) products, you need to make them usable with the new system.<a id="idx109"></a></p>
<table id="wq45" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use any ISV products and need to
reconnect them after performing a ServerPac or SystemPac installation.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td>
<p><strong>Target system software requirements:</strong></p></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Check with your ISVs to make
sure the product levels you are using support the new z/OS release, and then reconnect
your ISV products to the new release of z/OS following
the instructions provided by the ISVs. If any ISV products do not
need to be installed in the same libraries and zones as z/OS, place them in their own sets
of libraries and SMP/E zones. This means that, unless you have to
change ISV product code, such as installing PTFs, or obtain a new
level of the product, you will not need to reinstall it after you
install a new ServerPac or SystemPac.</p>
<p><strong>Reference information:</strong></p>
<ul>
<li>For a list of independent software vendors (ISVs) that support z/OS, as well as announcements,
testimonials, and other information, see <a href="http://www.ibm.com/systems/z/solutions/isv/">http://www.ibm.com/systems/z/solutions/isv/</a>. <a id="idx110"></a><a id="idx111"></a><a id="idx112"></a></li>
<li>For a directory of ISV products that support z/OS, see the Global Solutions Directory at <a href="http://www.ibm.com/software/solutions/isv">http://www.ibm.com/software/solutions/isv</a>.</li></ul>
<h3 id="at3geni">Reconnect subsystems</h3>
<p><strong>Description:</strong> If you use subsystems, you need
to make them usable with the new system.<a id="idx113"></a></p>
<table id="wq46" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you will use CICS, DB2&reg;, IMS, or NCP on your new system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure that any required coexistence
PTFs are installed before using the subsystem with the new z/OS system, as well as any required
SVCs, system modifications, parmlib setup, and proclib setup. Follow
the instructions for the subsystem that you need to reconnect.</p>
<p><strong>Reference information:</strong> Subsystem program
directories.</p>
<h3 id="at3genj">Update operational and other procedures</h3>
<p><strong>Description:</strong> Depending on which method you
used to install (ServerPac, CBPDO, or other deliverable), and which
functions you plan to exploit, you might need to update the operation,
automation, administration, security, backup, and recovery procedures
for your site. <a id="idx114"></a></p>
<table id="wq47" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review your operation, automation,
administration, security, backup, and recovery procedures, and make
any necessary changes depending on how you installed and which functions
you plan to exploit. Some possible changes are: </p>
<ul>
<li>Allowing applicable users access to new high-level qualifiers.
The default new high-level qualifiers are shown in <a href="#at3genf">Add references to new data sets and paths</a>.</li>
<li>Updating and testing your backup and recovery procedures to accommodate
the new target system.</li>
<li>Updating and testing any disaster recovery procedures.</li>
<li>Updating and testing any automation procedures to take advantage
of new functions.</li>
<li>Updating security system definitions, such as defining new users
and resources, permitting users to use new resources, and defining
new profiles in the RACF FACILITY
class.<a id="idx115"></a></li></ul>
<p><strong>Reference information:</strong> For the RACF FACILITY class profiles that
were added for z/OS UNIX, see >z/OS UNIX System Services Planning</a>.</p>
<h3 id="at3limi">Verify that virtual storage limits are set properly</h3>
<p><strong>Description:</strong> Virtual storage requirements
usually grow from release to release. You should review the virtual
storage limits you want to set. Generally, there are two areas of
concern: common areas (above and below the 16 MB line) and individual
address spaces. An increase in virtual storage for common areas reduces
the virtual storage size of all address spaces. An increase in virtual
storage for individual address spaces impacts only the individual
address spaces.<a id="idx116"></a><a id="idx117"></a></p>
<table id="wq48" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use IBM Health
Checker for z/OS to help determine
whether your virtual storage limits are set properly. The check RSM_MEMLIMIT
checks the current setting for the MEMLIMIT parameter in SMFPRM<var class="pv">xx</var>,
which affects the amount of virtual storage above the 2 GB bar that
is available to jobs. This check verifies that a nonzero MEMLIMIT
value is in use.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Determine how much virtual
storage use to allow above the 2 GB bar. While there is no practical
limit to the number of virtual addresses an address space can request
above the bar, the system can limit the amount of virtual storage
above the bar that an address space is allowed to use. The amount
of virtual storage above the bar is determined as follows. The MEMLIMIT
parameter in parmlib member SMFPRMxx sets the default system-wide
limit, which defaults to 2 GB as of z/OS V1R10
(and zero prior to z/OS V1R10).
However, the system-wide default MEMLIMIT can be overridden by specifying
REGION=0M or MEMLIMIT on JOB or EXEC statements in JCL. To set a limit
on the use of virtual storage above the bar, use the SMF exit IEFUSI.
For more information, see <a href="../com.ibm.zos.r13.ieaa500/limo.htm">Limiting
the use of memory objects</a> in >z/OS MVS Programming: Extended Addressability Guide</a>.<a id="idx118"></a></p>
<p>If you want to control the use of virtual storage above the 2 GB
bar, do one or more of the following:</p>
<ul>
<li>The MEMLIMIT default is 2 GB. If this 2 GB default value is acceptable
to you, no change to SMFPRM<var class="pv">xx</var> is necessary. (Prior to z/OS V1R10, the default MEMLIMIT
was zero, and you had to specify a nonzero MEMLIMIT in an active SMFPRM<var class="pv">xx</var> member
of parmlib to establish a system default other than zero for available
virtual storage above 2 GB.)</li>
<li>You can specify MEMLIMIT explicitly in JCL to override the system
default that was set (or allowed to default) in SMFPRM<var class="pv">xx</var>.</li>
<li>You can specify REGION=0M on the job statement in JCL to implicitly
set MEMLIMIT to NOLIMIT, which also overrides the system default (from
SMFPRM<var class="pv">xx</var>).</li>
<li>You can use IEFUSI both to establish a system default MEMLIMIT
for different classes of work (for example, job, TSO, STC) and limit
the amount of virtual storage that can be used above the bar, provided
that an explicit or implicit nonzero MEMLIMIT is in effect from JCL
or SMFPRM<var class="pv">xx</var>. As of z/OS V1R10,
keyword HONORIEFUSIREGION | NOHONORIEFUSIREGION is available in SCHED<var class="pv">xx</var> to
identify if the region and MEMLIMIT settings specified through or
otherwise affected by the IEFUSI exit are to take effect for a program.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>Information about how to evaluate the real storage configuration
can be found in the Washington Systems Center white paper <em>z/OS Performance:
Managing Processor Storage in a 64-bit Environment - V1</em> at <a href="http://www.ibm.com/support/techdocs/">http://www.ibm.com/support/techdocs</a>. (Search
for &quot;WP100269&quot;.) <a id="idx119"></a><a id="idx120"></a><a id="idx121"></a></li>
<li>For more information about controlling region size and region
limits using the IEFUSI exit, see >z/OS MVS Initialization and Tuning Guide</a>.</li>
<li>For more information about the HONORIEFUSIREGION keyword, see >z/OS MVS Initialization and Tuning Reference</a>.</li></ul>
<h3 id="at3back">Back virtual storage with sufficient real and auxiliary storage</h3>
<p><strong>Description:</strong>  As you exploit additional virtual
storage by defining additional address spaces or by exploiting memory
objects, ensure that you have defined sufficient real and auxiliary
storage. <a id="idx122"></a><a id="idx123"></a></p>
<table id="wq49" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Using an RMF&trade; report, determine whether additional real or
auxiliary storage is needed by checking the following real storage
concentration indicators:</p>
<ul>
<li>UIC and average available frames</li>
<li>Demand page rates</li>
<li>Percentage of auxiliary slots in use</li></ul>
<p><strong>Reference information:</strong> For more information
about memory objects, see >z/OS MVS Programming: Extended Addressability Guide</a> and
Washington Systems Center flash 10165 at <a href="http://www.ibm.com/support/techdocs/">http://www.ibm.com/support/techdocs</a>.
(Search for &quot;flash10165&quot;.)<a id="idx124"></a><a id="idx125"></a><a id="idx126"></a></p>
<h3 id="uplochk">Update your check customization for modified IBM Health Checker for z/OS checks</h3>
<p><strong>Description:</strong> Changes that IBM makes to the checks provided by IBM Health Checker for z/OS can affect any updates you might have made.<a id="idx127"></a></p>
<p>The checks that were changed by IBM in z/OS V1R13 are:</p>
<ul>
<li>SUP_HiperDispatch</li>
<li>XCF_SFM_CFSTRHANGTIME</li></ul>
<p id="nor13chks">The checks that were deleted by IBM in z/OS V1R13
are:</p>
<ul>
<li>CSVTAM_VIT_DSPSIZE</li>
<li>CSVTAM_VIT_SIZE</li></ul>
<p id="r12chks">The checks that were changed by IBM in z/OS V1R12
are:</p>
<ul>
<li>USS_PARMLIB</li>
<li>ZOSMIGREC_ROOT_FS_SIZE (introduced by APAR OA28684 for z/OS V1R9, V1R10 and V1R11)</li></ul>
<table id="wq50" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your checks
continue to work as you intend them to work.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>See <strong>Steps to take:</strong> below.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Look at the updated checks in >IBM Health Checker for z/OS: User&rsquo;s Guide</a>.</li>
<li>Review changes you made for those checks, in HZSPRM<var class="pv">xx</var> parmlib
members, for example.</li>
<li>Make any further updates for the checks to ensure that they continue
to work as intended.</li></ol>
<p><strong>Reference information:</strong> For complete information
about updating checks, see &quot;<a href="../com.ibm.zos.r13.e0zl100/mng.htm">Customizing
and managing checks</a>&quot; in >IBM Health Checker for z/OS: User&rsquo;s Guide</a>.</p>
<h3 id="at3gene">Remove deleted data sets, paths, and references</h3>
<p><strong>Description:</strong> Data sets and paths are routinely
removed from z/OS for reasons
such as consolidation of data sets and removal of elements and features.
You must determine whether these changes affect your environment.<a id="idx128"></a><a id="idx129"></a><a id="idx130"></a><a id="idx131"></a></p>
<table id="wq52" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Using <a href="#ldtab1">Table 3</a> as
a guide, remove data sets and paths that do not exist in the current
release. Also, remove references to them. You might find references
in the following places: </p>
<ul>
<li>Parmlib</li>
<li>Proclib</li>
<li>Logon procedures</li>
<li>Catalogs</li>
<li>Security definitions, including program control definitions</li>
<li>DFSMS ACS
routines</li>
<li><samp class="xph">/etc/profile</samp></li>
<li>SMP/E DDDEF entry</li>
<li>Backup and recovery procedures, as well as any references to them</li></ul>
<p>In the table, the data sets are identified as distribution library
(DLIB) data sets or target library data sets.</p>
<div>
<div class="notelisttitle" id="wq53">Notes:</div>
<ol type="1">
<li>Ensure that references to the DCE target library EUV.SEUVLINK
and DFS target library IOE.SIOELMOD have been removed from your LNKLST
concatenation.  Ensure that any reference to DCE target library EUV.SEUVLPA
has been removed from the LPALST concatenation.</li>
<li>Do not remove any data sets, paths, or references that are needed
by earlier-level systems until those systems no longer need
them.</li>
</ol></div>
<table id="ldtab1" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 3. Data sets and paths <strong>deleted</strong> from z/OS V1R13 and z/OS V1R12 (in alphabetic order by DDDEF name)</caption>
<thead valign="bottom">
<tr>
<th id="wq55" width="14%" align="left" valign="bottom">DDDEF</th>
<th id="wq56" width="21%" align="left" valign="bottom">Data set name or path (high-level
qualifiers are defaults)</th>
<th id="wq57" width="9%" align="left">DLIB or target</th>
<th id="wq58" width="21%" align="left" valign="bottom">From element or feature</th>
<th id="wq59" width="12%" align="left" valign="bottom">When deleted</th>
<th id="wq60" width="21%" align="left" valign="bottom">Why deleted</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq55">ACIMHFS</td>
<td headers="wq56">CIM.ACIMHFS</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ACIMMOD1</td>
<td headers="wq56">CIM.ACIMMOD1</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ACIMPLUG</td>
<td headers="wq56">CIM.ACIMPLUG</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ABPAHFS</td>
<td headers="wq56">BPA.ABPAHFS</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ACMXDBRM</td>
<td headers="wq56">CMX.ACMXDBRM</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ACMXHFS</td>
<td headers="wq56">CMX.ACMXHFS</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">ACUNIMG</td>
<td headers="wq56">SYS1.ACUNIMG</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">BCP</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">Unicode Services will no longer ship the
pre-built image SYS1.ACUNIMG</td>
</tr>
<tr>
<td headers="wq55">AEUVACF</td>
<td headers="wq56">EUV.AEUVACF</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVDBRM</td>
<td headers="wq56">EUV.AEUVDBRM</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVEXEC</td>
<td headers="wq56">EUV.AEUVEXEC</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVEXP</td>
<td headers="wq56">EUV.AEUVEXP</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHDR</td>
<td headers="wq56">EUV.AEUVHDR</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHDRK</td>
<td headers="wq56">EUV.AEUVHDRK</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHDCP</td>
<td headers="wq56">EUV.AEUVHDCP</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHETC</td>
<td headers="wq56">EUV.AEUVHETC</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHINC</td>
<td headers="wq56">EUV.AEUVHINC</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHJPN</td>
<td headers="wq56">EUV.AEUVHJPN</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHLBR</td>
<td headers="wq56">EUV.AEUVHLBR</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHTCL</td>
<td headers="wq56">EUV.AEUVHTCL</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVHXMP</td>
<td headers="wq56">EUV.AEUVHXMP</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVIDL</td>
<td headers="wq56">EUV.AEUVIDL</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVLIB</td>
<td headers="wq56">EUV.AEUVLIB</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVLIBK</td>
<td headers="wq56">EUV.AEUVLIBK</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVLIBS</td>
<td headers="wq56">EUV.AEUVLIBS</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVLINK</td>
<td headers="wq56">EUV.AEUVLINK</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVMSG</td>
<td headers="wq56">EUV.AEUVMSG</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVMSGJ</td>
<td headers="wq56">EUV.AEUVMSGJ</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVPNL</td>
<td headers="wq56">EUV.AEUVPNL</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVPNLJ</td>
<td headers="wq56">EUV.AEUVPNLJ</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AEUVPRC</td>
<td headers="wq56">EUV.AEUVPRC</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">AIOELMOD</td>
<td headers="wq56">IOE.AIOELMOD</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DFS</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">No load modules are installed in these libraries
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq55">AIOEMSGE</td>
<td headers="wq56">IOE.AIOEMSGE</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DFS</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">English message library is no longer provided
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq55">AIOEMSGJ</td>
<td headers="wq56">IOE.AIOEMSGJ</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DFS</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">Japanese message library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq55">AIOEPNLE</td>
<td headers="wq56">IOE.AIOEPNLE</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DFS</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">English panel library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq55">AIOEPNLJ</td>
<td headers="wq56">IOE.AIOEPNLJ</td>
<td headers="wq57">DLIB</td>
<td headers="wq58">DFS</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">Japanese panel library is not provided in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq55">SBPABIN</td>
<td headers="wq56">/usr/lpp/bpa/bin/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SBPAINC</td>
<td headers="wq56">/usr/lpp/bpa/include/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SBPALIB</td>
<td headers="wq56">/usr/lpp/bpa/lib/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SBPAMSC</td>
<td headers="wq56">/usr/lpp/bpa/nls/msg/C/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SBPAMJPN</td>
<td headers="wq56">/usr/lpp/bpa/nls/msg/Ja_JP/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SBPASAMP</td>
<td headers="wq56">/usr/lpp/bpa/samples/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCEEUMAP</td>
<td headers="wq56">CEE.SCEEUMAP</td>
<td headers="wq57">Target</td>
<td headers="wq58">Language
Environment</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">The SCEEUMAP data set will no longer be
shipped.</td>
</tr>
<tr>
<td headers="wq55">SCIMLIB</td>
<td headers="wq56">/usr/lpp/cim/lib/IBM</td>
<td headers="wq57">Target</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">SCIMBIN</td>
<td headers="wq56">/usr/lpp/cim/bin/IBM</td>
<td headers="wq57">Target</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">SCIMPWS</td>
<td headers="wq56">/usr/lpp/cim/IBM</td>
<td headers="wq57">Target</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">SCIMPLUG</td>
<td headers="wq56">/usr/lpp/cim/plugin/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">SCIMXML</td>
<td headers="wq56">CIM.SCIMXML</td>
<td headers="wq57">Target</td>
<td headers="wq58">msys for Setup</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">msys for Setup removed from z/OS</td>
</tr>
<tr>
<td headers="wq55">SCMXBIN</td>
<td headers="wq56">/usr/lpp/cmx/bin/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXDBRM</td>
<td headers="wq56">CMX.SCMXDBRM</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXINC</td>
<td headers="wq56">/usr/lpp/cmx/include/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXLIB</td>
<td headers="wq56">/usr/lpp/cmx/lib/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXMJPN</td>
<td headers="wq56">/usr/lpp/cmx/nls/msg/Ja_JP/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXMSC</td>
<td headers="wq56">/usr/lpp/cmx/nls/msg/C/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCMXSAMP</td>
<td headers="wq56">/usr/lpp/cmx/samples/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">z/OS UNIX System Services</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">z/OS UNIX System Services Connection
Manager removed from z/OS.</td>
</tr>
<tr>
<td headers="wq55">SCUNIMG</td>
<td headers="wq56">SYS1.SCUNIMG</td>
<td headers="wq57">Target</td>
<td headers="wq58">BCP</td>
<td headers="wq59">z/OS V1R12</td>
<td headers="wq60">Unicode Services will no longer ship the
pre-built image SYS1.SCUNIMG. See <a href="#cunidhc">Remove reference to Unicode Services pre-built image
CUNIDHC2</a> for more
information.</td>
</tr>
<tr>
<td headers="wq55">SEUVACF</td>
<td headers="wq56">EUV.SEUVACF</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVDBRM</td>
<td headers="wq56">EUV.SEUVDBRM</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVEXEC</td>
<td headers="wq56">EUV.SEUVEXEC</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVEXP</td>
<td headers="wq56">EUV.SEUVEXP</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHBIN</td>
<td headers="wq56">/usr/lpp/dce/bin/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHDCP</td>
<td headers="wq56">/usr/lpp/dce/dcecp/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHDR</td>
<td headers="wq56">EUV.SEUVHDR</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHDRK</td>
<td headers="wq56">EUV.SEUVHDRK</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHETC</td>
<td headers="wq56">/usr/lpp/dce/etc/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHINC</td>
<td headers="wq56">/usr/lpp/dce/share/include/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHJPN</td>
<td headers="wq56">/usr/lpp/dce/lib/nls/msg/Ja_JP/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHLBR</td>
<td headers="wq56">/usr/lpp/dce/lib/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHTCL</td>
<td headers="wq56">/usr/lpp/dce/tcl/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVHXMP</td>
<td headers="wq56">/usr/lpp/dce/examples/IBM/</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVLIB</td>
<td headers="wq56">EUV.SEUVLIB</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVLIBK</td>
<td headers="wq56">EUV.SEUVLIBK</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVLIBS</td>
<td headers="wq56">EUV.SEUVLIBS</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td headers="wq55">SEUVIDL</td>
<td headers="wq56">EUV.SEUVIDL</td>
<td headers="wq57">Target</td>
<td headers="wq58">DCE</td>
<td headers="wq59">z/OS V1R13</td>
<td headers="wq60">DCE removed from z/OS. For considerations about safely removing DCE
userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
</tbody>
</table>
<table width="100%" summary="" border="1" frame="border" rules="all">
<tbody valign="top">
<tr>
<td>SEUVLINK</td>
<td>EUV.SEUVLINK</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVLPA</td>
<td>EUV.SEUVLPA</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVMSG</td>
<td>EUV.SEUVMSG</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVMSGJ</td>
<td>EUV.SEUVMSGJ</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVPNL</td>
<td>EUV.SEUVPNL</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVPNLJ</td>
<td>EUV.SEUVPNLJ</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SEUVPRC</td>
<td>EUV.SEUVPRC</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td>DCE removed from z/OS.
For considerations about safely removing DCE userids, see <a href="#dcegone">Stop using Computing Environment (DCE) and DCE Security Server</a>.</td>
</tr>
<tr>
<td>SFOMUCMP</td>
<td>/usr/lib/nls/locale/ucmap/IBM/</td>
<td>Target</td>
<td>Language
Environment</td>
<td>z/OS V1R12</td>
<td>HFS directory will no longer be shipped.</td>
</tr>
<tr>
<td>SFOMUCNV</td>
<td>/usr/lib/nls/locale/uconvtable/IBM/</td>
<td>Target</td>
<td>Language
Environment</td>
<td>z/OS V1R12</td>
<td>HFS directory will no longer be shipped.</td>
</tr>
<tr>
<td>SIOELMOD</td>
<td>IOE.SIOELMOD</td>
<td>Target</td>
<td>DFS</td>
<td>z/OS V1R13</td>
<td>No load modules are installed in these libraries
as of z/OS V1R13.</td>
</tr>
<tr>
<td>SIOEMSGE</td>
<td>IOE.SIOEMSGE</td>
<td>Target</td>
<td>DFS</td>
<td>z/OS V1R13</td>
<td>English message library is no longer provided
as of z/OS V1R13.</td>
</tr>
<tr>
<td>SIOEMSGJ</td>
<td>IOE.SIOEMSGJ</td>
<td>Target</td>
<td>DFS</td>
<td>z/OS V1R13</td>
<td>Japanese message library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td>SIOEPNLE</td>
<td>IOE.SIOEPNLE</td>
<td>Target</td>
<td>DFS</td>
<td>z/OS V1R13</td>
<td>English panel library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td>SIOEPNLJ</td>
<td>IOE.SIOEPNLJ</td>
<td>Target</td>
<td>DFS</td>
<td>z/OS V1R13</td>
<td>Japanese panel library is not provided in z/OS V1R13.</td>
</tr>
<tr>
<td>None. See comments in <strong>Why deleted</strong>.</td>
<td>/etc/dce</td>
<td>Target</td>
<td>DCE</td>
<td>z/OS V1R13</td>
<td> These entries do not have DDDEFs associated
with the directories; all files and directories can be removed. Note
that if <strong>/krb5</strong> is a symbolic link to the<strong> /etc/dce</strong> directory, deleting <strong>/etc/dce</strong> removes
it as well. Ensure that when you delete <strong>/etc/dce</strong> you
are not removing anything for <strong>/krb5</strong> that is
defined for Kerberos.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information:</strong> None.</p>
<h3 id="at3genf">Add references to new data sets and paths</h3>
<p><strong>Description:</strong> New data sets and paths are
routinely added to z/OS for
reasons such as consolidation of data sets and addition of new elements
and features. You must determine whether these additions affect your
environment.<a id="idx132"></a><a id="idx133"></a></p>
<table id="wq61" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Using <a href="#dsadded">Table 4</a> as
a guide, add references in the following places for data sets and
paths that have been added to z/OS: </p>
<ul>
<li>Parmlib</li>
<li>Proclib</li>
<li>Logon procedures</li>
<li>Catalogs</li>
<li>Security definitions, including program control definitions</li>
<li>DFSMS ACS
routines</li>
<li>Any backup and recovery procedures.</li></ul>
<p><strong>Rules:</strong> Some of the data sets shipped with z/OS are PDSEs and are most likely
in your link list. If one or more are in your link list and on your
system residence volume, adhere to the following PDSE sharing rules
to avoid data set corruption:<a id="idx134"></a><a id="idx135"></a></p>
<ul>
<li>If you specified PDSESHARING(NORMAL), do not share PDSE data sets
beyond the scope of the global resource serialization complex.</li>
<li>If you specified PDSESHARING(EXTENDED), do not share PDSE data
sets beyond the scope of the sysplex.</li></ul>
<table id="dsadded" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 4. Data sets <strong>added</strong> to z/OS V1R13 and z/OS V1R12 (in alphabetic order by DDDEF name)</caption>
<thead valign="bottom">
<tr>
<th id="wq62" width="14%" align="left" valign="bottom">DDDEF</th>
<th id="wq63" width="21%" align="left" valign="bottom">Data set name (high-level qualifiers
are defaults) or path</th>
<th id="wq64" width="9%" align="left">DLIB or target</th>
<th id="wq65" width="21%" align="left" valign="bottom">To element or feature</th>
<th id="wq66" width="12%" align="left" valign="bottom">When added</th>
<th id="wq67" width="21%" align="left" valign="bottom">Why added</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq62">SERBHFS</td>
<td headers="wq63">/usr/lpp/gpm/IBM</td>
<td headers="wq64">Target</td>
<td headers="wq65">RMF</td>
<td headers="wq66">z/OS V1R13.</td>
<td headers="wq67">New RMF file
system path for RMF XP.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information:</strong> None.</p>
<h3 id="af32m">Accommodate new address spaces</h3>
<p><strong>Description:</strong> The MAXUSER value in parmlib
member IEASYS<var class="pv">xx</var> specifies a value that the system uses to
limit the number of jobs and started tasks that can run concurrently
during a given IPL. You might want to increase your MAXUSER value
to take new address spaces into account.</p><a id="idx136"></a>
<p>There are two new address spaces in z/OS V1R13. </p>
<ul>
<li>GPM4CIM is an address space to be used for cross-platform performance
management with RMF XP. You can
start it by using procedure SYS1.PROCLIB(GPM4CIM) from the console,
as started task, with the  following command:
<pre class="xmp"><code>s gpm4cim[.identifier],os=A|X|Z</code></pre>Since
you can run multiple GPM4CIM instances simultaneously, it is recommended
to assign an identifier that you can use for subsequent STOP or MODIFY
commands. You may already have created the userID GPMSERVE as owner
of the GPMSERVE procedure. The GPM4CIM started task can be assigned
to the same userID with the following command:
<pre class="xmp"><code>RDEFINE STARTED GPM4CIM.* STDATA(USER(GPMSERVE) TRUSTED(YES))</code></pre>For
more information, refer to >z/OS RMF User&rsquo;s Guide</a>.</li>
<li>The Runtime Diagnostics address space HZR will be a persistent
address space. When the HZR address space is started with the START
command <span class="pk">S HZR,SUB=MSTR</span>, it will remain active until stopped
with the STOP command <span class="pk">P HZR</span>.  To analyze a system, enter
the <span class="pk">MODIFY HZR,ANALYZE</span> command. See <a href="#commndxx">Start Runtime Diagnostics at system initialization</a> for
more information.</li></ul>
<p>There was one new address space in z/OS V1R12.
ARC<var class="pv">n</var>RST<var class="pv">y</var> is the address space identifier for full-volume
recovery from dump, where <var class="pv">n</var> is the DFSMShsm host ID and <var class="pv">y</var> is
the instance of the DFSMSdss started task (a number from 1 to 4).
Data set recovery from dump will still use ARC<var class="pv">n</var>REST. See <a href="#hsmdssaddr">DFSMShsm: Configure your security system to permit started
procedures using new address space identifier</a> for more information.</p>
<table id="wq68" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>
<ul>
<li>BCP for HZR.</li>
<li>RMF for GPM4CIM.</li></ul></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>z/OS V1R13 for GPM4CIM
and HZR.</li>
<li>z/OS V1R12 for ARC<var class="pv">n</var>RST<var class="pv">y</var>.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>
<ul>
<li>z/OS V1R12 and z/OS V1R11</li></ul></td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your MAXUSER
value in parmlib member IEASYS<var class="pv">xx</var> is adequate.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If necessary, increase your
MAXUSER value in parmlib member IEASYS<var class="pv">xx</var> to take the new
address spaces into account. One way to find out how many address
spaces you use is to issue the <samp class="xph">DISPLAY A,L</samp> command and
total the address spaces in the IEE114I and IEE115I messages on the
old and new systems. </p>
<div>
<div class="notelisttitle" id="wq69">Notes:</div>
<ol type="1">
<li>A modest overspecification of MAXUSER should not hurt system performance.</li>
<li>The number of total address spaces is the sum of M/S, TS USERS,
SYSAS, and INITS.</li>
<li>If you change your MAXUSER value, you must re-IPL to make
the change effective.</li>
</ol></div>
<p><strong>Reference information:</strong> For more information
about the MAXUSER parameter, including its interaction with the RSVSTRT
and RSVNONR parameters and factors that contribute to the number of
active address spaces, see &quot;<a href="../com.ibm.zos.r13.ieae200/syssps.htm">statements
and parameters for IEASYSxx</a>&quot; in >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h2 id="wq71">Migration actions for everyone after the first IPL of z/OS V1R13</h2>
<p>None.</p>
<h1 id="au1hard">Hardware migration actions</h1>
<p>This topic describes hardware migration actions. The information
in this topic is not specifically related to migrating to z/OS V1R13; it only applies if
you are changing hardware. Therefore, this topic does not categorize
the actions in terms of when they should be performed (before installing,
before the first IPL, or after the first IPL).</p><a id="idx137"></a><a id="idx138"></a>
<h2 id="znext2">Migrate to an IBM zEnterprise zEC12 server</h2>
<p><strong>Description:</strong> An IBM zEnterprise zEC12 can include
the following in a zEnterprise environment: </p>
<ul>
<li> IBM zEnterprise zEC12 server Central Processing Complex (CPC)</li>
<li>zEnterprise BladeCenter&reg; Extension (zBX)
Model 003 with its integrated optimizers or select IBM blades</li>
<li>zEnterprise Unified
Resource Manager (Unified Resource Manager)</li></ul>
<p> The zEC12 is the newest IBM System z server and is distinct
from the earlier zEnterprise and
other servers. In this publication the IBM zEnterprise zEC12 server is referred
to as the model zEC12 server.</p>
<p> In a Parallel Sysplex you
can include the following servers along with the IBM zEnterprise zEC12</p>
<ul>
<li>zEnterprise servers
(z196 or z114)</li>
<li>z10 EC</li>
<li>z10 BC servers.</li></ul><a id="idx139"></a><a id="idx140"></a><a id="idx141"></a><a id="idx142"></a><a id="idx143"></a><a id="idx144"></a><a id="idx145"></a><a id="idx146"></a><a id="idx147"></a><a id="idx148"></a><a id="idx149"></a><a id="idx150"></a><a id="idx151"></a><a id="idx152"></a><a id="idx153"></a><a id="idx154"></a>
<p>The specific zEC12 functions exploited by z/OS depend on the z/OS release.
See <a href="#znextfunc2">Table 5</a>. Availability and other restrictions
are noted at the end of the table. PTFs might be required for many
of these functions.  See <a href="#znextbef2">Actions you can take before you order a zEC12 server</a> for information
about finding the appropriate PTFs.</p>
<table id="znextfunc2" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 5. New IBM zEnterprise zEC12 server functions supported by z/OS V1R11, z/OS V1R12, and z/OS V1R13</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq72" width="37%" align="left"><span>zEC12 function</span></th>
<th id="wq73" width="20%" align="left"><span>R11 (For support, see Notes)</span></th>
<th id="wq74" width="20%" align="left">R12</th>
<th id="wq75" width="20%" align="left">R13</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td colspan="3" align="center" headers="wq72 wq73 wq74"><strong>Included in base z/OS support</strong></td>
<td align="center" headers="wq75"></td>
</tr>
<tr>
<td headers="wq72">Base support</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">OSA-Express4S (GbE LX and SX, 1000BASE-T,
10 GbE LR and SR)</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">FICON&reg; Express&reg; 8S (CHPID FC)</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">InfiniBand Coupling Link</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">CPU measurement facility</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">New z/Architecture&reg; assembler
instructions</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">Crypto Express4S (#0865) Toleration, which treats
Crypto Express4S cryptographic co-processors and accelerators as CryptoExpress3
co-processors and accelerators</td>
<td headers="wq73">Y (requires Cryptographic Support
for z/OS V1R9-V1R11 Web deliverable.)</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">Crypto Express4S (#0865) support of X9.8 Pin,
64 Bit, HMAC, CKDS Constraint Relief, PCI Audit, Elliptic Curve Cryptography
(ECC) Hardware (HW) support, CBC Key Wrap, and PKA RSA OAEP with SHA-256
algorithm</td>
<td headers="wq73">Y (requires Cryptographic Support
for z/OS V1R10-V1R12 Web deliverable.)</td>
<td headers="wq74">Y (requires Cryptographic Support for z/OS V1R10-V1R12 Web deliverable)</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">Crypto Express4S (#0865) support of Expanded
Key support for AES algorithm, enhanced ANSI TR-31 Secure Key Exchange,
PIN block decimalization table protection, PKA RSA OAEP with SHA-256
algorithm, or additional Elliptic Curve Cryptography (ECC) functions</td>
<td headers="wq73">Y (requires Cryptographic Support
for z/OS V1R11-V1R13 Web deliverable.)</td>
<td headers="wq74">Y (requires Cryptographic Support for z/OS V1R11-V1R13 Web deliverable)</td>
<td headers="wq75">Y (requires Cryptographic Support for z/OS V1R11-V1R13 Web deliverable)</td>
</tr>
<tr>
<td headers="wq72">GRS FICON CTC
toleration</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td colspan="3" align="center" headers="wq72 wq73 wq74"><strong>Exploitation of z/OS support</strong></td>
<td align="center" headers="wq75"></td>
</tr>
<tr>
<td headers="wq72">Coupling Facility Control Code (CFCC) Level
18</td>
<td headers="wq73">N</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">IBM zEnterprise Unified Resource
Manager</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">IBM zEnterprise BladeCenter Extension (zBX)
Model 003</td>
<td headers="wq73">Y</td>
<td headers="wq74">Y</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">Crypto Express4S (#0865) exploitation including Enterprise
Security PKSC11-Hardware Security Module (HSM), DUKPT for MAC and
Data Encryption, cipher Text Translate CCA Verb, PKDS/TKDS Constraint
Relief, Random Number Cache, FIPS on Demand, or Wrapping Keys with
Strong Keys</td>
<td headers="wq73">N</td>
<td headers="wq74">Y (requires Cryptographic Support for z/OS V1R12-V1R13 Web deliverable)</td>
<td headers="wq75">Y (requires Cryptographic Support for z/OS V1R12-V1R13 Web deliverable)</td>
</tr>
<tr>
<td headers="wq72"> IBM System z Advanced Workload
Analysis Reporter (IBM zAware)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">Flash Express.
(For Flash Express exploitation,
see <strong>Notes</strong>.)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y (requires the z/OS V1R13 RSM Enablement Offering Web deliverable)</td>
</tr>
<tr>
<td headers="wq72">Pageable 1 MB Large Page Support. (For availability,
see <strong>Notes</strong>.)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y (requires the z/OS V1R13 RSM Enablement Offering Web deliverable)</td>
</tr>
<tr>
<td headers="wq72">Dynamic reconfiguration support for Flash Express. (For availability,
see <strong>Notes</strong>.)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y (requires the z/OS V1R13 RSM Enablement Offering Web deliverable
and additional PTFs)</td>
</tr>
<tr>
<td headers="wq72">2 GB Large Page support. (For availability,
see <strong>Notes</strong>.)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y (requires the z/OS V1R13 RSM Enablement Offering Web deliverable
and additional PTFs)</td>
</tr>
<tr>
<td headers="wq72">Optional PLPA/common page data set support.
(For availability, see <strong>Notes</strong>.)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y (requires the z/OS V1R13 RSM Enablement Offering Web deliverable
and additional PTFs)</td>
</tr>
<tr>
<td headers="wq72">Support for IBM Java exploitation of Transactional
Execution Facility.</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td headers="wq72">New z/Architecture&reg;
instructions: XL C/C++ ARCH(10)TUNE(10)</td>
<td headers="wq73">N</td>
<td headers="wq74">N</td>
<td headers="wq75">Y</td>
</tr>
<tr>
<td colspan="4" headers="wq72 wq73 wq74 wq75"><strong>Legend:</strong>
<ul class="simple">
<li>Y = supported.</li>
<li>N = not supported</li></ul>
<div>
<div class="notelisttitle" id="wq76">Notes:</div>
<ol type="1">
<li>After September 28, 2012 the z/OS Lifecycle
Extension for z/OS V1R11 (5657-A01)
is required for support.</li>
<li>Planned availability of z/OS exploitation
of Flash Express and Pageable
1 MB large pages is December 14, 2012 with the z/OS V1R13 RSM Enablement Offering Web deliverable.</li>
<li>Planned availability of dynamic reconfiguration support
for Flash Express, 2 GB
Large Page, and optional PLPA/common page data set support is 1Q2013
with the PTFs installed on top of the z/OS V1R13
RSM Enablement Offering Web deliverable.</li>
</ol></div></td>
</tr>
</tbody>
</table>
<table id="wq78" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td width="25%"><strong>Element or feature:</strong></td>
<td width="75%">Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>IBM zEnterprise zEC12, which first shipped September 2012.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11 or when running
V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime before you introduce a zEC12 server
into your environment.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS V1R13, V1R12 or V1R11 on a zEC12 server,
or if you want to run a Coupling Facility on a zEC12 server.  If
you will run only a Coupling Facility on a zEC12 system, then only
the sysplex-related actions below are relevant.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>
<ul>
<li>A zEC12</li>
<li>Additional hardware required for specific functions.
<ul>
<li>IBM devices previously attached
to IBM System z10, z196 and zSeries servers
are supported for attachment to zEC12 channels, unless otherwise
noted. The subject I/O devices must meet FICON architecture requirements</li>
<li>IBM zAware requires the IBM zAware server firmware (FC #0011,
#0101, and #0102)</li>
<li>Flash Express requires
FC #0402</li>
<li>Use of IBM WebSphere DataPower&reg; Integration Appliance
XI50 for zEnterprise (DataPower XI50z) or select IBM BladeCenter PS701 Express blades
or IBM BladeCenter HX5 blades requires a zEnterprise BladeCenter Extension (zBX)
Model 003</li></ul></li></ul></td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>
<ol type="1">
<li>See the list of PTFs in the Software Service Level section of
the PSP buckets.</li>
<li>See <strong>Support is delivered by service and web deliverables</strong> described
in <a href="#znextrec2">General recommendations and considerations for a zEC12 server</a> and<strong> Install the necessary z/OS service</strong>, as indicated
in PSP buckets described in <a href="#znextbef2">Actions you can take before you order a zEC12 server</a></li></ol></td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>
<ul>
<li>It is recommended that you install and run the required service
on your existing server. This will enable you to fall back from a
hardware perspective, yet maintain your software level.</li>
<li>If you have not installed the preconditioning and exploitation
PTFs for CFCC Level 17, note that those PTFs are required to be installed
throughout your sysplex before you can implement CFCC Level 18.</li></ul></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>See <a href="#znextres2">Restrictions for a zEC12 server</a>.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig,
is added to z/OS V1R12 and
available on z/OS V1R11 with
APAR OA30476. This check will verify that HiperDispatch is enabled
on a zEC12 system.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the <a href="#znextrec2">General recommendations and considerations for a zEC12 server</a>, adhere to the <a href="#znextres2">Restrictions for a zEC12 server</a>, and perform
the tasks described in the various topics below.</p>
<h3 id="znextrec2">General recommendations and considerations for a zEC12 server</h3>
<p>As you plan your migration to a zEnterprise server, consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are
new when coming from a z196, z114, z10 EC
or a z10 BC server.</strong> Migration
to an IBM zEnterprise zEC12 server has, as its base, a migration to the z196 or
z114 servers. This means that if you are migrating to a zEnterprise server from a
z196 or z114 server, and have performed the migration actions associated
with the z196 or z114, you have fewer migration actions than if you
were migrating from an earlier generation server and have not yet
performed the migration actions associated with these servers. There
are, in fact, very few new migration actions to perform on z/OS for a zEnterprise zEC12 server if you have already migrated
to a z196 or z114 server. It is important to note that you can migrate
directly to a zEnterprise zEC12 server
without installing the intermediate servers, but you still need to
ensure that any migration considerations are satisfied for the servers
that you &quot;skipped.&quot; To read about z196, z114, z10 EC and z10 BC server migration actions, see <a href="#mignext">Migrate to an IBM zEnterprise z196 or z114
server</a> and <a href="#migrz10">Migrate to a System z10 server</a>.</li>
<li><strong>Support is delivered by service and web deliverables.</strong> The
base support for an IBM zEnterprise zEC12 server is delivered by service (PTFs).
The list of PTFs required is listed in the PSP bucket (Upgrade 2827DEVICE,
Subset 2827/ZOS) and identified by the SMP/E Fix Category <samp class="xph">IBM.Device.Server.zEC12-2827</samp>.
Some exploitation is delivered by service (PTFs) and is listed in
the same PSP bucket. Other exploitation requires a web deliverable
to be downloaded and installed. The cryptographic support for the zEC12 server
continues to be delivered as an web deliverable packaged as an FMID.
Depending on the cryptographic functions that you want to use, you
might be able to use earlier cryptographic web deliverables. For Flash Express support (including dynamic
reconfiguration support and optional PLPA/COMMON page data set support),
pageable 1 MB Large Page support, and 2 GB Large Page Support, a separate
web deliverable (the z/OS V1R13
RSM Enablement Offering web deliverable) is required. (See &quot;Decide
on the steps you will take for your migration to a zEC12 server&quot; in <a href="#znextbef2">Actions you can take before you order a zEC12 server</a> for further information.)</li>
<li><strong>Larger coupling facility structure sizes might
be necessary.</strong> When you change coupling facility control code
(CFCC) levels, your coupling facility structure sizes might change.
 IBM zEnterprise zEC12 servers initially ship with CFCC level 18. If, as part of
your migration to a zEC12 server, you change CFCC levels, you might
have larger structure sizes than you did previously. If your CFCC
levels are identical, structure sizes are not expected to change when
you migrate from a previous server to a newer generation server. In
addition, similar to CF Level 17, ensure that the CF LPAR has at least
512MB of storage.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To
minimize the amount of change (and therefore risk) that you experience
at one time, do not migrate your software release level at the same
time that you migrate your hardware.</li>
<li><strong>Update SCRT to latest version.</strong> If you use
SCRT, make sure it is at the latest level. This is a requirement for
sub-capacity pricing, as well as when you upgrade servers. The latest
level of SCRT can be downloaded from the SCRT web site at <a href="http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li></ol>
<h3 id="znextres2">Restrictions for a zEC12 server</h3>
<p>Restrictions associated with zEnterprise servers
are:</p>
<ol type="1">
<li><strong>Functional limitations:</strong> Not all zEC12 functions
are available in every z/OS release.
See <a href="#znextfunc2">Table 5</a> for a list of the zEC12 functions
available in each z/OS release.
Some functions have migration or exploitation considerations (see <a href="#znextbef2">Actions you can take before you order a zEC12 server</a> and <a href="#znextaft2">Migration and exploitation considerations for zEC12 server
functions</a>. )  Many functions
are enabled or disabled, based on the presence or absence of the required
hardware and software. If you wish to position yourself to exploit
any new zEC12 functions, you can install the software and hardware
in either order; that is, there is no requirement to install either
software or hardware first to exploit a specific function. However,
because of outage windows and testing considerations, you might want
to consider installing all the required software first, then upgrading
the hardware and, finally, updating your customization to exploit
the new functions.</li>
<li><strong>zEC12 servers in a sysplex:</strong> 
<ul>
<li>A Parallel
Sysplex that contains an IBM zEnterprise (zEC12) either
for a z/OS image or a CF image
can only contain other IBM zEnterprise (zEC12) servers
or zEnterprise z196,
z114, z10 EC, or z10 BC servers. If you are running z/OS on any servers earlier than a z10 EC or z10 BC
server, you cannot add a zEC12 server to that sysplex; that is,
you will not be able to perform rolling IPLs to introduce a zEC12 server
if you have any of the earlier servers either as z/OS images or coupling facility images in the sysplex.
The earlier servers in the sysplex must be upgraded to System z10 or later to have zEC12 servers
supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier
server, and you intend to introduce a zEC12 server into that sysplex,
you must migrate those images to a System z10 (or
later) server before introducing the zEC12 server.
<p>If you are
currently using ESCON CTCs
for GRS ring configurations within a sysplex, consider using XCF 
signalling in a GRS ring configuration. XCF sysplex signalling is
preferred instead of GRS CTC connections. Note that ESCON CTCs are not supported on an IBM zEnterprise (zEC12)
and if you choose not to convert to XCF signalling, you will have
to install toleration maintenance to enable GRS to use FICON for GRS ring configurations.
This support does not enhance the robustness of GRS-managed CTCs and
the toleration must be installed across GRS complex. See <a href="#grsficon">Migrate to GRS-managed FICON CTCs</a>.</p></li>
<li>The Integrated Cluster Bus 4 (ICB-4) Coupling Links are
not supported on a zEC12 CPC. Use 12x InfiniBand coupling links,
which are designed to replace Integrated Cluster Bus 4 (ICB-4),
and to complement 1x InfiniBand and ISC-3 on a zEC12 server.
InfiniBand coupling can provide significantly improved service times
compared to ISC-3s for distances up to 150 meters. You can
read about InfiniBand coupling links in <em>IBM System z Connectivity Handbook</em> (SG24-5444).
See <a href="#phoicb4">Migrate from ICB-4 to Infiniband coupling links</a></li>
<li>The zEC12 server <strong>cannot</strong> be connected
to a Sysplex Timer&reg; (9037-002).
The Server Time Protocol (STP) feature is the follow-on to
the Sysplex Timer.
STP is designed to allow multiple servers and coupling facilities
to maintain time synchronization with each other without requiring
a Sysplex Timer. STP
is a hardware feature of the zEC12, z196, z114, z10 EC, z10 BC, z9 EC, z9 BC,
z990, and z890 servers. To implement STP, see the STP web site and
the publications and other resources listed there. See <a href="#sttostp">Migrate from a Sysplex
Timer to STP</a>. The STP web site is at <a href="http://www.ibm.com/systems/z/advantages/pso/stp.html">http://www.ibm.com/systems/z/advantages/pso/stp.html </a>.
<p>The
STP design introduced a concept called Coordinated Timing Network
(CTN). A CTN is a collection of servers and coupling facilities that
are time-synchronized to a time value called Coordinated Server
Time. A CTN can be configured in two ways:</p>
<ul>
<li>STP-only CTN, which does not require a Sysplex Timer.</li>
<li>Mixed-CTN (External Time Reference and STP), which does
require a Sysplex Timer.
<p>The Sysplex Timer provides
the timekeeping information in a Mixed-CTN. Even though the zEC12 servers
do not support attachment to a Sysplex
Timer, they can participate in a Mixed-CTN that has a z10 server synchronized to the Sysplex Timer. This maintains
the capability for enterprises to concurrently migrate from an existing
External Time Reference (ETR) to a Mixed-CTN and from a Mixed-CTN
to an STP-only CTN.</p></li></ul>
<p>Note that the zEC12 will be the last high-end server
to support connections to an STP Mixed-CTN. All servers in the network
must be configured in STP-only mode. Consider migrating your servers
that require time synchronization, such as to support a base or Parallel
Sysplex(R), to the Server Time Protocol (STP).</p></li></ul></li>
<li>For a list of functions on the zEC12 server that are planned
to be discontinued on future servers, see <a href="#z2012hw">Accommodate functions for the zEC12 server to be discontinued
on future servers</a></li>
<li><strong>Unsupported hardware features:</strong> The following
hardware features <strong>cannot</strong> be ordered
 (and cannot be carried forward from an upgrade on an earlier
server to the zEC12 server. 
<ul>
<li>Power&reg; Sequence Controller
(PSC).</li>
<li>FICON Express. You should begin migrating to FICON Express8S channels.</li>
<li>FICON Express2. You should
begin migrating to FICON Express8S
channels.</li>
<li>FICON Express4 4KM LX.
You should begin migrating to FICON Express8S
channels.</li>
<li>OSA Express2. You should begin migrating to OSA-Express4S (GbE
LX and SX, 1000BASE-T, 10 GbE LR and SR).</li>
<li>ESCON. You should begin
migrating to FICON Express8S
channels.</li>
<li>Dial up modems. The currently available Network Time Protocol
(NTP) server option for ETS, as well as Internet time services available
using broadband connections, can be used to provide the same degree
of accuracy as dial-up time services. You should begin migrating from
dial-up modems to broadband for RSF connections</li></ul>
<p><strong>Carry forward hardware features:</strong> The
following hardware features are not orderable on zEC12 servers.
If they are installed on your existing server at the time of an upgrade
to a zEC12 server, they may be retained or carried forward. </p>
<ul>
<li>ISC-3. You should begin migrating from ISC-3 features (#0217,
#0218, #0219) to 12x InfiniBand (#0163 - HCA2-O or #0171- HCA3-O fanout)
or 1x InfiniBand (#0168 - HCA2-O LR or #0170 - HCA3-O LR fanout) coupling
links.</li>
<li>FICON Express4 10KM LX.
You should begin migrating to FICON Express8S
channels.</li>
<li>FICON Express4 SX. You
should begin migrating to FICON Express8S
channels</li></ul></li></ol>
<h3 id="znextbef2">Actions you can take before you order a zEC12 server</h3>
<p>You can perform the following migration actions before you order
or install a zEnterprise server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in
which the zEC12 server will participate.</strong> See <a href="#znextres2">Restrictions for a zEC12 server</a> for a description of the limitations when using zEC12 servers
with certain earlier servers in a Parallel Sysplex.</li>
<li><strong>Implement STP (or a Mixed-CTN) timing
network.</strong> This action is necessitated because Sysplex Timers (9037-002)
are not supported on zEC12 servers. See <a href="#sttostp">Migrate from a Sysplex
Timer to STP</a>.</li>
<li><strong>Migrate from ICB-4 to InfiniBand coupling links.</strong> This
action is necessitated because ICB-4 links are not supported on  zEC12 servers.
If desired, you can take this action after you order a  zEC12 server,
as you upgrade to the new server. See <a href="#phoicb4">Migrate from ICB-4 to Infiniband coupling links</a>.</li>
<li><strong>Migrate from unsupported hardware features to
newer technology.</strong> This action is necessitated because FICON Express, FICON Express2,
Crypto Express2, and OSA-Express2 10 GbE LR are not supported on zEnterprise servers. See <a href="#znextres2">Restrictions for a zEC12 server</a>, <a href="#at3ruio">Replace unsupported devices</a>, and <a href="#au3ndv">Provide for new device installations</a>.</li>
<li><em></em><strong>Install the
necessary z/OS service, as
indicated in PSP buckets.</strong> For an IBM zEnterprise zEC12 CPC, PTFs are identified
in the 2827DEVICE PSP bucket (Subset 2827/ZOS). For an IBM zEnterprise BladeCenter Extension
(zBX) attached to yourIBM zEnterprise (zEC12)
CPC, the PTFs are identified in the 2458DEVICE PSP bucket (Subset
2458/ZOS). In each PSP bucket, the content is dependent on the z/OS release you will run on the zEnterprise server. If you
reviewed the PSP buckets some time ago, review them again to ensure
that any newly identified z/OS service
has been installed. To assist you in determining if you have the recommended
service (identified in these PSP buckets) installed on your system,
you can use the SMP/E REPORT MISSINGFIX command in conjunction with
the FIXCAT type of HOLDDATA, as follows:<a id="idx155"></a><a id="idx156"></a><a id="idx157"></a><a id="idx158"></a>
<ol type="a">
<li>Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s). Use your normal
service acquisition portals or download the two (2) year HOLDDATA
directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you select <strong>Full</strong> from the Download NOW
column (last 730 days) to receive the FIXCAT HOLDDATA, as the other
files do not contain FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify one or more of the following
Fix Categories (FIXCAT):
<ul>
<li>IBM.Device.Server.zEC12-2827</li>
<li>IBM.Device.Server.zEC12-2827.Exploitation</li>
<li>IBM.Device.Server..zEC12-2827.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server..zEC12-2827.ServerTimeProtocol</li>
<li>IBM.Device.Server..zEC12-2827.zHighPerformanceFICON</li></ul>
<p>The report will identify any missing coexistence and fallback
PTFs for that system. For complete information about the REPORT MISSINGFIX
command, see >SMP/E Commands</a>.</p></li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
PTFs recommended for the zEnterprise servers.</li></ol>
<div>
<div class="notelisttitle" id="wq84">Notes:</div>
<ol type="a">
<li>You can also use Service Link&rsquo;s PSP Service Extraction tool.</li>
<li>Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010,
you can no longer use that tool to identify missing PSP bucket service.
You should use SMP/E's Fix Category support, which is fully integrated
into SMP/E procedures and IBM product
and service deliverables.</li>
</ol></div></li>
<li><strong>Run CFSIZER.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on higher
CFCC levels than they were previously, run the Coupling Facility Structure
Sizer (CFSIZER) tool to find out if you have to increase coupling
facility structure sizes. <span>zEC12 servers are initially
shipped with CFCC Level 18; prepare to make the necessary changes
as indicated by the tool. You can find the CFSIZER tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>. Also see <a href="#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></span>.</li>
<li><strong id="icsfstp2">Decide on the steps you will take
for your migration to a zEC12 server.</strong>  In addition to the steps
listed here in <a href="#znextbef2">Actions you can take before you order a zEC12 server</a>, as a guide, also see <a href="#znextaft2">Migration and exploitation considerations for zEC12 server
functions</a>. Also, note the following <span>web deliverables
considerations</span>:
<ul>
<li>The level of function provided for cryptographic support
differs by z/OS release and
the ICSF web deliverable that is installed. For z/OS V1R11 toleration support is provided by PTFs
installed on top of the Cryptographic Support for z/OS V1R9-V1R11 Web deliverable (the z/OS Lifecycle Extension for z/OS V1.11 (5657-A01) is required
for support). Note that toleration PTFs are available for other cryptographic
web deliverables as well. For z/OS V1R12
and z/OS V1R13 exploitation
of IBM zEnterprise (zEC12) Crypto Express4S requires the
installation of the Cryptographic Support for <span>z/OS V1R12-V1R13</span> (FMID HCR77A0),
available September 2012. Note that this level of ICSF is not integrated
in z/OS V1R13 and will need
to be downloaded and installed even after ordering a z/OS V1R13 ServerPac. 
<p>For z/OS V1R11, the z/OS Lifecycle
Extension for z/OS V1.11 (5657-A01)
is required for support after September 28, 2012:</p>
<ul>
<li> If you require Crypto Express4S toleration, which treats Crypto
Express4S cryptographic coprocessors and accelerators as Crypto Express3
coprocessors and accelerators on a zEC12 server, minimally you must
install the Cryptographic Support for z/OS V1R9-V1R11
web deliverable (FMID HCR7770) or higher and a toleration PTF.</li>
<li>If you require Crypto Express4S support of X9.8 Pin, 64 Bit, HMAC,
CKDS Constraint Relief, PCI Audit, ECC HW Support, CBC Key Wrap, and
PKA RSA OAEP with SHA-256 algorithm, minimally you must install the
Cryptographic Support for z/OS V1R10-V1R12
web deliverable (FMID HCR7780) or higher and a toleration PTF.</li>
<li>If you require Crypto Express4S support of Expanded key support
for AES algorithm, enhanced ANSI TR-31 Secure Key Exchange, PIN block
decimalization table protection, PKA RSA OAEP with SHA-256 algorithm,
or additional Elliptic Curve Cryptography (ECC) functions, you must
install the Cryptographic Support for z/OS V1R11-V1R13
web deliverable (FMID HCR7790) and a toleration PTF.</li></ul>
<p>For z/OS V1R12,
consider the following:</p>
<ul>
<li>If you require Crypto Express4S toleration, which treats
Crypto Express4S cryptographic coprocessors and accelerators as Crypto
Express3 coprocessors and accelerators on a zEC12 server, minimally
you must install the toleration PTFs listed in the PSP bucket.</li>
<li>If you require Crypto Express4S support of X9.8 Pin,
64 Bit, HMAC, CKDS Constraint Relief, PCI Audit, ECC HW Support, CBC
Key Wrap, and PKA RSA OAEP with SHA-256 algorithm, minimally you must
install the Cryptographic Support for z/OS V1R10-V1R12
web deliverable (FMID HCR7780) or higher, and <span>a toleration
PTF.</span></li>
<li>If you require Crypto Express4S support of Expanded key
support for AES algorithm, enhanced ANSI TR-31 Secure Key Exchange,
PIN block decimalization table protection, PKA RSA OAEP with SHA-256
algorithm, or additional Elliptic Curve Cryptography (ECC) functions,
you must install the Cryptographic Support for z/OS V1R11-V1R13 web deliverable (FMID HCR7790)
and <span>a toleration PTF.</span></li>
<li>If you require Crypto Express4S exploitation including:
Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT
for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS
Constraint Relief, Random Number Cache, FIPS on Demand, or Wrapping
Keys with Strong Keys, you must install the Cryptographic Support
for z/OS V1R12-V1R13 web deliverable
(FMID HCR77A0), available September 2012.</li></ul>
<p>For z/OS V1R13
consider the following:</p>
<ul>
<li>If you require Crypto Express4S toleration, which treats Crypto
Express4S cryptographic coprocessors and accelerators as Crypto Express3
coprocessors and accelerators on a zEC12 server, minimally you must
install the toleration PTFs listed in the PSP bucket.</li>
<li>If you require Crypto Express4S support of Expanded key support
for AES algorithm, enhanced ANSI TR-31 Secure Key Exchange, PIN block
decimalization table protection, PKA RSA OAEP with SHA-256 algorithm,
or additional Elliptic Curve Cryptography (ECC) functions, you must
install the Cryptographic Support for z/OS V1R11-V1R13
web deliverable (FMID HCR7790) and a toleration PTF.</li>
<li>If you require Crypto Express4S exploitation including:
Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT
for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS
Constraint Relief, Random Number Cache, FIPS on Demand, or Wrapping
Keys with Strong Keys, you must install the Cryptographic Support
for z/OS V1R12-V1R13 web deliverable
(FMID HCR77A0), available September 2012.</li></ul>
<div>
<div class="notetitle" id="wq86">Note:</div>
<div class="notebody"> ICSF, specifically HCR7770, HCR7780, HCR7790,
and HCR77A0 require coexistence PTFs to be installed on earlier levels
of ICSF if they share keys in their sysplex. To assist in identifying
the coexistence service, the following Fix Categories can be used: 
<ul>
<li>IBM.Coexistence.ICSF.z/OS_V1R9-V1R11-HCR7770</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R12-V1R13-HCR77A0</li></ul></div></div></li>
<li>If you want to exploit Flash Express (including dynamic reconfiguration support
and optional PLPA/COMMON page data set support, and pageable 1 MB
Large Page support) or 2 GB Large Page Support, the z/OS V1R13 RSM Enablement Offering web deliverable
is required. This is a separate web deliverable from any of the Cryptographic
Support web deliverables and can be installed independently of those
web deliverables.</li></ul></li>
<li><strong>Review the new mnemonics introduced for the zEC12 server.</strong> The
new mnemonics might collide with (be identical to) the names of assembler
macro instructions you use or provide. In the event of such collisions,
the HLASM's default opcode table (UNI) will treat specification
of these names as instructions when APAR PM49761 is installed.  This
will probably cause assembler error messages and possibly cause generation
of incorrect object code. 
<p>If you write programs in Assembler Language,
you should compare the list provided in <cite>z/Architecture Principles
of Operation</cite>, SA22-7832,
to the names of assembler macro instructions you use or provide, to
identify any such conflicts or collisions that would occur following
installation of HLASM APAR PM49761. If a conflict is identified, take
one of the following actions:</p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify PARM='...OPTABLE(YOP)...' (or
some other earlier opcode table).</li>
<li>Specify a separate ASMAOPT file containing assembler options,
such as in the previous method (this method requires no changes to
source code or JCL).</li>
<li>Add, as the first statement of your source program, *PROCESS OPTABLE(YOP).</li>
<li>Specify the PROFILE option either in JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the front of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique (where XXX
is a sample mnemonic):
<pre class="xmp"><code>Assume the default OPTABLE(UNI) is in effect
			XXX   a,b       new instruction
			PUSH  ACONTROL  save current optable definition
			ACONTROL OPTABLE(YOP)   switch optable dynamically
			XXX   r,s,t     macro invocation
			POP   ACONTROL  restore previous definition
			XXX   c,d       new instruction</code></pre></li></ul>
<p>For more information about HLASM's opcode table,
see >HLASM Programmer&rsquo;s Guide</a>.</p></li>
<li><strong>Plan for changes to your global resource serialization
complex with the zEC12 server. </strong> If you use a global resource
serialization ring complex that spans more systems than is part of
the sysplex or does not use sysplex signalling for communications
within the complex, you need to take migration actions. Instead of
using global resource serialization ring, consider using the global
resource serialization star configuration in a sysplex. You can take
the following actions before you install the zEC12 server:
<ul>
<li>Migrate to a Parallel
Sysplex that uses the recommended global resource serialization
star complex.</li>
<li>Convert to a basic sysplex that uses XCF sysplex signalling with
global resource serialization ring instead of GRS-managed channel-to-channel
(CTC) communications.</li></ul>Optionally, you can install maintenance for the zEC12 server
that provides toleration for FICON-based CTC communications, but understand
that this toleration does not improve the robustness of GRS-managed
CTC communications, and you must install the toleration maintenance
on all systems in the GRS complex. See <a href="#grsficon">Migrate to GRS-managed FICON CTCs</a>.</li></ol>
<h3 id="znextaft2">Migration and exploitation considerations for zEC12 server
functions</h3>
<p>The following zEC12 functions are available on z/OS V1R11 and later releases:</p>
<ol type="1">
<li><strong>Consider the number of CPU measurement facility
counters for zEC12</strong>. The number of CPU measurement facility
counters for zEC12 is increased to 80. More extended counters mean
more internal storage is required. While the structure of the SMF
113 Record does not change, the values, interpretations, and frequency
of certain sections do change; therefore, current tools using the
data need to be updated for zEC12.
<p>For example, consider the following
SMF record fields: </p>
<ul>
<li>SMF113_2_CtrVN1 identifies how to interpret the Basic and Problem
counter set. As described in <cite>The IBM CPU Measurement Facility Extended Counters Definition for z10 and z196</cite>, SA23-2260,
this field is set to 1 (for z10,
z196, and z114) or 2 (zEC12).</li>
<li>SMF113_2_CtrVN2 identifies how to interpret the Crypto and Extended
counter sets. As described in SA23-2260 this will be set to 1 (z10), 2 (z196 or z114) or 3 (zEC12).</li></ul></li></ol>
<p>The following zEC12 functions are available on z/OS V1R13 and later releases:</p>
<ol type="1">
<li><strong>IBM zAware
system</strong>. IBM zAware is designed
to offer a real-time, continuous learning, and diagnostics capability
intended to help you pinpoint and resolve potential problems quickly
enough to minimize impacts to your business. After you order a zEC12 you
can prepare to set up an IBM zAware
environment <span>by defining the IBM zAware logical partition</span>, making PARMLIB
updates, defining log streams, and network definitions. For more information,
see <cite>IBM System
z Advanced  Workload Analysis Reporter (IBM zAware) Guide</cite>,  (SC27-2623) and <cite></cite>.</li>
<li><strong> Java exploitation
of the Transactional Execution Facility.</strong>  z/OS V1.13 with PTFs provides support for Java exploitation of the Transaction
Execution Facility on IBM zEnterprise zEC12. This
function is designed to help eliminate software locking overhead that
can impact performance. Transactional Execution will offer increased
scalability and parallelism to drive higher transaction throughput. Java exploitation is planned with IBM 31-bit SDK for z/OS, Java technology
Edition, V7.0.0 (5655-W43) and SDK7 IBM 64-bit
SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W44).
<p>Also
note that the z/OS V1.13 XL
C/C++ compiler when ARCH(10) is specified will provide hardware built-in
functions to enable applications to use the Transactional Execution
Facility.</p></li></ol>
<p>The following zEC12 functions are available on z/OS V1R13 if you have the z/OS V1R13 RSM Enablement Offering
Web deliverable installed:</p>
<ol type="1">
<li><strong>z/OS V1R13
RSM Enablement Offering Web deliverable</strong>. Installing the z/OS V1R13 RSM Enablement Offering
Web deliverable will increase the size of the nucleus by roughly 380K
when you IPL. You might need to analyze your private storage usage <span>when</span> you IPL with the web deliverable installed. IPLing
with the web deliverable installed will also add 24K of ESQA per CPU
defined to that LPAR. See <a href="#nucleus">Accommodate increase in nucleus size for  the z/OS V1R13 RSM Enablement Offering Web deliverable</a> and <a href="#esqa">Accommodate increase in ESQA with the z/OS V1R13 RSM Enablement Offering Web deliverable</a>.</li>
<li><strong>Flash Express</strong>.
Flash Express is designed
to help improve availability and handling of paging workload spikes.
Using Flash Express can
help availability by reducing latency from paging delays that can
occur at the start of the workday or during other transitional periods.
It is also designed to help eliminate delays that can occur when collecting
diagnostic data during failures. To exploit Flash Express, download and install the z/OS V1R13 RSM Enablement Offering Web deliverable
and optionally update IEASYSxx in PARMLIB to specify the new PAGESCM
parameter. For exploitation details, see<cite></cite>, <cite></cite>, and <cite></cite>.</li>
<li><strong>2 GB large pages (planned
for exploitation availability in the first quarter of 2013)</strong>.
2 GB large pages can help improve processor performance by enabling
middleware to use 2 GB large pages support. 2 GB large pages allow
for a single translation lookaside buffer (TLB) entry to fulfill many
more address translations than either a large page or ordinary base
page. 2 GB large pages provides exploiters much better TLB coverage
and therefore provides better performance by decreasing the number
of TLB misses that an application incurs, less time spent converting
virtual addresses into physical addresses, and the usage of less real
storage to maintain DAT structures.  Exploitation is planned for the IBM 31-bit SDK for z/OS, Java technology
Edition, V7.0.0 (5655-W43) and SDK7 IBM 64-bit
SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W44). To exploit
2 GB Large pages, install the z/OS V1.13
RSM Enablement Offering Web deliverable and the appropriate middleware
exploitation support (see the PSP Bucket (Upgrade: 2827/DEVICE, Subset:
2827/ZOS) for more information on the required software requirements);
and update your current LFAREA parameter. For exploitation details,
see <cite></cite>.</li>
<li><strong>Pageable large (1MB) pages</strong>. z/OS is designed to help improve
processor performance by supporting middleware exploitation of pageable
large (1 MB) pages. Exploitation is planned for Language Environment when
used with a run-time option, by IBM DB2 10 for z/OS (5605-DB2) and Java,
with the IBM 31-bit SDK for z/OS, Java technology
Edition, V7.0.0 (5655-W43) and SDK7 IBM 64-bit
SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W44) . Ensure
that the exploiting software is installed. For exploitation details,
see <cite></cite>.</li>
<li><strong>Optional pageable link pack area (PLPA)
and common page data sets optional (planned for availability in the
first quarter of 2013)</strong>. This option is used only for quick and
warm start IPLs. To exploit this capability install the z/OS V1.13 RSM Enablement Offering
Web deliverable and then update your PLPA and COMMON pages data sets
in IEASYSxx. For exploitation details, see <cite></cite>.</li>
<li><strong>Dynamic reconfiguration for Flash Express (planned for exploitation
availability in the first quarter of 2013)</strong>. This function is
a follow on for Flash Express.</li></ol>
<h3 id="z2012hw">Accommodate functions for the zEC12 server to be discontinued
on future servers</h3>
<p><strong>Description:</strong> The following changes in hardware
support could affect your environment. Make appropriate changes as
needed.</p>
<ul>
<li><strong>STP Mixed CTN</strong>. The zEC12 server
is planned to be the last high end IBM server
to support connections to an STP Mixed CTN. This includes the Sysplex Timer (9037).
Future servers that require time synchronization, such as to support
a base or Parallel Sysplex,
will require Server Time Protocol (STP), and all servers in that network
must be configured in STP-only mode.</li>
<li><strong>Removal of support for Ethernet half-duplex operation
and 10 Mbps link data rate</strong>. The OSA-Express4S 1000BASE-T Ethernet
feature is planned to be the last copper Ethernet feature to support
half-duplex operation and a 10 Mbps link data rate. The zEC12 server
is planned to be the last IBM System z server to support
half-duplex operation and a 10 Mbps link data rate for copper Ethernet
environments. Any future 1000BASE-T Ethernet feature will support
full-duplex operation and auto-negotiation to 100 or 1000 Mbps exclusively.</li>
<li><strong>Removal of ISC-3 support on System z</strong>. The zEC12 is
planned to be the last high-end System
z server to offer support of the InterSystem Channel-3 (ISC-3)
for Parallel Sysplex environments
at extended distances. ISC-3 will not be supported on future high-end System z servers as a carry
forward function on an upgrade. Previously it was announced that the IBM zEnterprise 196 (z196) and IBM zEnterprise 114
(z114) servers were to be the last to offer ordering of ISC-3. Enterprises
should continue migrating from ISC-3 features (#0217, #0218, #0219)
to 12x InfiniBand (#0171 - HCA3-O fanout) or 1x InfiniBand (#0170
- HCA3-O LR fanout) coupling links.</li>
<li><strong>Removal of OSA-Express3 support on System z.</strong> The zEC12 server
is planned to be the last high-end System
z server to offer support of the Open System Adapter-Express3
(OSA-Express3 #3362, #3363, #3367, #3370, #3371) family of features.
You should continue to migrate from the OSA-Express3 features to the
OSA-Express4S features (#0404, #0405, #0406, #0407, #0408).</li>
<li><strong>Removal of FICON Express4
support on System z</strong>.
The zEC12 server is planned to be the last high-end System z server to offer support
of the FICON Express4 features
(#3321, #3322). You should continue to migrate from the FICON Express4 features to the FICON Express8S features (#0409,
#0410).</li>
<li><strong>Removal of Crypto Express3 support on System z</strong>. The zEC12.
server is planned to be the last high-end System z server to offer support of the Crypto Express3
feature (#0864). You should continue to migrate from the Crypto Express3
feature to the Crypto Express4S feature (#0865).</li>
<li><strong>IBM System z Application Assist
Processor (zAAP):</strong> IBM zEC12 is
planned to be the last high-end System
z server to offer support for zAAP specialty engine processors. IBM plans to converge zAAP and zIIP
specialty engines onto zIIPs. This is intended to help simplify capacity
planning and performance management, while still providing the capability
to offload many workloads, which can help you control software costs.</li></ul>
<div>
<div class="notetitle" id="wq90">Note:</div>
<div class="notebody">IBM's statements regarding its plans, directions,
and intent are subject to change or withdrawal without notice at IBM's
sole discretion. Information regarding potential future products is
intended to outline our general product direction and it should not
be relied on in making a purchasing decision. The information mentioned
regarding potential future products is not a commitment, promise,
or legal obligation to deliver any material, code, or functionality.
Information about potential future products may not be incorporated
into any contract. The development, release, and timing of any future
features or functionality described for our products remains at our
sole discretion</div></div>
<table id="wq91" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>28 August 2012 in U.S. Announcement Letter.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before migrating to a zEC12 server.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you are using a zEC12 server
because this is the last server that will support the changes mentioned
in "Description" above.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>See &quot;Description&quot; above.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Take into account
the statements in &quot;<strong>Description</strong>&quot; above
as you migrate to zEC12.</p>
<h2 id="mignext">Migrate to an IBM zEnterprise z196 or z114
server</h2>
<p><strong>Description:</strong> An IBM zEnterprise 196 (z196) and IBM zEnterprise 114 (z114) System includes a Central
Processing Complex (CPC), the IBM zEnterprise 196 (z196) server,
the IBM zEnterprise 114 (z114) server, the zEnterprise BladeCenter Extension (zBX)
with its integrated optimizers or select IBM blades,
and the zEnterprise Unified
Resource Manager (Unified Resource Manager).</p><a id="idx159"></a><a id="idx160"></a><a id="idx161"></a><a id="idx162"></a><a id="idx163"></a><a id="idx164"></a><a id="idx165"></a><a id="idx166"></a><a id="idx167"></a><a id="idx168"></a><a id="idx169"></a><a id="idx170"></a>
<p>The specific zEnterprise functions
exploited by z/OS depend on
the z/OS release. See <a href="#znextfunc">Table 6</a>.</p>
<table id="znextfunc" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 6. zEnterprise functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq92" width="37%" align="left">zEnterprise function</th>
<th id="wq93" width="20%" align="left">R11</th>
<th id="wq94" width="20%" align="left">R12</th>
<th id="wq95" width="20%" align="left">R13</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td colspan="3" align="center" headers="wq92 wq93 wq94"><strong>Included in base z/OS support</strong></td>
<td align="center" headers="wq95"></td>
</tr>
<tr>
<td headers="wq92">Base support</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">OSA-Express3 (GbE LX and SX, 1000BASE-T,
10 GbE LR and SR)</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">InfiniBand Coupling Links</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">New z/Architecture instructions
<p> (Support
differs by release. z/OS V1R12, z/OS V1R13, and higher, include
XL C/C++ support for ARCH(9) and TUNE(9) options.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Up to 128 Coupling Links CHPIDs</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">FICON Express8
(CHPID FC)</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">PCIe-based I/O infrastructure - FICON Express8S and OSA Express4S</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">IFAURP reporting</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Tolerate greater than 64 CPs per server</td>
<td headers="wq93">Y (z196 only)</td>
<td headers="wq94">Y (z196 only)</td>
<td headers="wq95">Y (z196 only)</td>
</tr>
<tr>
<td headers="wq92">Crypto toleration
<p>(Support differs depending
on level of ICSF installed. PTF required.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">OSA-Express3 (CHPID type OSD) with or without
exploitation of two ports per CHPID</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Up to 32 HiperSockets&trade;</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">RMF postprocessor
crypto activity report - 4096 bit</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">CPU measurement facility (HIS)</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Greater than 64 CPs per LPAR</td>
<td headers="wq93">Y (z196 only)</td>
<td headers="wq94">Y (z196 only)</td>
<td headers="wq95">Y (z196 only)</td>
</tr>
<tr>
<td headers="wq92">HiperDispatch cache and affinity node changes</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">HiperDispatch serviceability
<p> (Support differs
by release.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">LE high register resolution</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td colspan="3" align="center" headers="wq92 wq93 wq94"><strong>Exploitation of z/OS support</strong></td>
<td align="center" headers="wq95"></td>
</tr>
<tr>
<td headers="wq92">Power save
mode</td>
<td headers="wq93">Y (z196 only)</td>
<td headers="wq94">Y (z196 only)</td>
<td headers="wq95">Y (z196 only)</td>
</tr>
<tr>
<td headers="wq92">Coupling Facility Control Code (CFCC) Level
17</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Three subchannel sets</td>
<td headers="wq93">Y (z196 only)</td>
<td headers="wq94">Y (z196 only)</td>
<td headers="wq95">Y (z196 only)</td>
</tr>
<tr>
<td headers="wq92">IPL from alternate subchannel set</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">IBM zEnterprise Unified Resource
Manager</td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">IBM zEnterprise BladeCenter Extension (zBX) 
<p>(Support
for OSA CHPID types OSM and OSX.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Crypto exploitation of ANSI X9.8 Pin security, enhanced Common
Cryptographic Architecture (CCA), 64 Bit, CP Assist for Cryptographic
Function (CPACF) enhancements, Secure Keyed-Hash Message Authentication
Code (HMAC), CKDS Constraint Relief, PCI Audit, Elliptical Curve Cryptography
(ECC) Digital Signature Algorithm, and CBC Key Wrap, PKA RSA OEAP
with SHA-256. 
<p>(z/OS V1R11
and z/OS V1R12 require Cryptographic
Support for z/OS V1R10-V1R12
[FMID HCR7780] web deliverable.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Crypto exploitation.  For Crypto Express3 feature when defined
as a coprocessor: expanded support for AES algorithm, enhanced ANSI
TR-31 Secure Key Exchange, PIN block decimalization table protection,
and PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
Cryptography (ECC) functions.
<p>(Requires Cryptographic Support for z/OS V1R11-V1R13 [FMID HCR7790
web deliverable available September 2011.)</p></td>
<td headers="wq93">Y</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">z/OS Discovery
and AutoConfiguration (zDAC) support</td>
<td headers="wq93">N</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">New OSA display command</td>
<td headers="wq93">N</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">OSA-Express3 and OSA-Express4S Inbound
Workload Queuing (IWQ)</td>
<td headers="wq93">N</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Inbound workload queuing for Enterprise Extender
for the OSA-Express4S and OSA-Express3 features when defined as CHPID
types OSD or OSX</td>
<td headers="wq93">N</td>
<td headers="wq94">N</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">OSA-Express4S checksum offload for LPAR-to-LPAR
traffic  for IPv4 and IPv6 packets (CHPID type OSD or OSX)</td>
<td headers="wq93">N</td>
<td headers="wq94">N</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">OSA-Express4S large send for IPv6 packets (CHPID
types OSD and OSX)</td>
<td headers="wq93">N</td>
<td headers="wq94">N</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">zHPF performance improvements for FICON Express8S</td>
<td headers="wq93">N</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td headers="wq92">Hipersocket optimization for intraensemble data
networks (IEDN) (IBM Statement
of Direction)<sup>5</sup></td>
<td headers="wq93">N</td>
<td headers="wq94">N</td>
<td headers="wq95">N</td>
</tr>
<tr>
<td headers="wq92">Non-disruptive CF dump</td>
<td headers="wq93">N</td>
<td headers="wq94">Y</td>
<td headers="wq95">Y</td>
</tr>
<tr>
<td colspan="3" headers="wq92 wq93 wq94"><strong>Legend:</strong>
<ul class="simple">
<li>Y = supported.</li>
<li>N = not supported</li></ul>
<div>
<div class="notetitle" id="wq96">Note:</div>
<div class="notebody">PTFs may be required.  Refer to <a href="#znextbef">Actions you can take before you order a z196 and z114 server</a> for information about finding the appropriate PTFs.</div></div></td>
<td headers="wq95"></td>
</tr>
</tbody>
</table>
<table id="wq97" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td width="25%"><strong>Element or feature:</strong></td>
<td width="75%">Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>The IBM zEnterprise 114 (z114), which
shipped in September 2011.</li>
<li>The IBM zEnterprise 196 (z196), which
first shipped in September 2010.</li>
<li>The IBM zEnterprise BladeCenter Extension (zBX),
which shipped November 2010.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime before you introduce a zEnterprise server into your
environment.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS V1R13, V1R12 or V1R11 on a zEnterprise server, or if
you want to run a Coupling Facility on a zEnterprise server.  If you will run only a Coupling
Facility on a zEnterprise system,
then only the sysplex-related actions below are relevant.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>
<ul>
<li>A z196, or a z114 server.</li>
<li>Additional hardware required for specific functions.
<ul>
<li>zDAC requires:
<ul>
<li>FICON channels attached
to switches (either FICON Express8
or FICON Express4 -
[CHPID type: FC])</li>
<li>Up-to-date controller microcode</li>
<li>Up-to-date switch microcode</li></ul></li>
<li>IBM zEnterprise Blade Center Extension (zBX) is required
for the IBM Smart Analytics
Optimizer for DB2 for z/OS V1.1, the IBM WebSphere DataPower Integration Appliance
XI50 for zEnterprise (DataPower XI50z), and select POWER7&reg; and IBM System x&reg; blades.</li>
<li>An IBM System Storage&reg; DS5020
is required for IBM Smart Analytics
Optimizer.</li></ul></li></ul></td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>
<ol type="1">
<li>See the list of PTFs in the Software Service Level section of
the PSP buckets.</li>
<li>See <strong>Install the necessary z/OS service, as indicated in PSP buckets</strong> described
in <a href="#znextrec2">General recommendations and considerations for a zEC12 server</a>.</li></ol></td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>
<ul>
<li>It is recommended that you install and run the zEnterprise required service
on your existing server. This will enable you to fall back from a
hardware perspective, yet maintain your software level.</li>
<li>If you haven't installed the preconditioning and exploitation
PTFs for CFCC Level 17, Note that those PTFs are required to be installed
throughout your sysplex before implementing CFCC Level 18.</li></ul></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>See <a href="#znextres2">Restrictions for a zEC12 server</a>.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig,
is added to z/OS V1R12 and
available on z/OS V1R11 with
APAR OA30476. This check will verify that HiperDispatch is enabled
on a zEnterprise system.
(For more information, see "HiperDispatch cache and affinity node
changes" in <a href="#znextexp">Migration and exploitation considerations for z196 and z114
server functions</a>.)</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the <a href="#znextrec2">General recommendations and considerations for a zEC12 server</a>, adhere to the <a href="#znextres2">Restrictions for a zEC12 server</a>, and perform
the tasks described in the various topics below.</p>
<h3 id="znextrec">General recommendations and considerations for z196 and z114
servers</h3>
<p>As you plan your migration to a zEnterprise server, consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when
coming from a z10 EC or a z10 BC server.</strong> Migration to
a zEnterprise server
has, as its base, a migration to the z10 EC
or z10 BC servers. This means
that if you are migrating to a zEnterprise server
from a z10 EC or z10 BC server, and have performed the migration actions
associated with the z10 EC or z10 BC, you have fewer migration
actions than if you were migrating from a server prior to the z10 EC or z10 BC and have not yet performed the migration actions
associated with these servers. There are, in fact, very few new migration
actions to perform on z/OS for
a zEnterprise server
if you have already migrated to a z10 EC
or z10 BC server. It is important
to note that you can migrate directly to a zEnterprise server without installing the<span> intermediate
servers, but</span> you still need to ensure that any migration considerations
are satisfied for the servers that you &quot;skipped.&quot; To read about z10 EC and z10 BC server migration actions, see <a href="#migrz10">Migrate to a System z10 server</a>.</li>
<li><strong>Support is delivered by service (and FMID web
deliverables for ICSF).</strong> The delta (from a z10 EC or z10 BC)
support for a zEnterprise server,
excluding cryptographic support, is delivered by service (PTFs). 
The cryptographic support for the zEnterprise server
continues to be FMIDs, many of which are still available in web deliverables.
Different ICSF web deliverables, providing different levels of support,
are available for different releases of z/OS.
(See &quot;Decide on the steps you will take for your migration to a zEnterprise server&quot; in <a href="#znextbef">Actions you can take before you order a z196 and z114 server</a> for further information.)</li>
<li><strong>Larger coupling facility structure sizes might
be necessary.</strong> When you change coupling facility control code
(CFCC) levels, your coupling facility structure sizes might change. zEnterprise servers initially
ship with CFCC level 17. If, as part of your migration to a zEnterprise server, you change
CFCC levels (either by placing a coupling facility on the zEnterprise server or by
moving the coupling facility to a z10 EC
or z10 BC at a later CFCC level),
you might have larger structure sizes than you did previously. If
your CFCC levels are identical, structure sizes are not expected to
change when you migrate from a previous server to a newer generation
server.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To
minimize the amount of change (and therefore risk) that you experience
at one time, do not migrate your software release level at the same
time that you migrate your hardware.</li>
<li><strong>Update SCRT to latest version.</strong> If you use
SCRT, make sure it is at the latest level. This is a requirement for
vWLC, as well as when you upgrade servers. The latest level of SCRT
can be downloaded from the SCRT web site at <a href="http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li></ol>
<h3 id="znextres">Restrictions for a z196 or z114 server</h3>
<p>Restrictions associated with zEnterprise servers
are:</p>
<ol type="1">
<li><strong>Functional limitations:</strong> Not all zEnterprise functions are
available in every z/OS release.
See <a href="#znextfunc">Table 6</a> for a list of the zEnterprise functions available
in each z/OS release. Some
functions have migration or exploitation considerations (see <a href="#znextexp">Migration and exploitation considerations for z196 and z114
server functions</a>).  Many functions are enabled or disabled, based
on the presence or absence of the required hardware and software.
If you wish to position yourself to exploit any new zEnterprise functions, you
can install the software and hardware in either order; that is, there
is no requirement to install either software or hardware first to
exploit a specific function. However, because of outage windows and
testing considerations, you might want to consider installing all
the required software first, then upgrading the hardware and, finally,
updating your customization to exploit the new functions.</li>
<li><strong>zEnterprise servers
in a sysplex:</strong> 
<ul>
<li>zEnterprise servers
z196 and z114 are supported in a Parallel Sysplex with other zEnterprise z196 and z114 servers, z10 EC and z10 BC
servers, and z9 EC and z9 BC servers.  If you introduce zEC12 into
a sysplex with z196 or z114, ensure that you have satisfied the zEC12 sysplex
restrictions in <a href="#znextres2">Restrictions for a zEC12 server</a>. If you are running z/OS on zSeries z900, z800, z990, or z890 servers, then
you cannot add a zEnterprise z196
and z114 server to that sysplex. That is, you will not be able to
perform rolling IPLs to introduce a zEnterprise z196 and z114 server if you have any
of the earlier (pre-System z) servers either as z/OS images or coupling facility images in the sysplex.
The earlier servers in the sysplex must be upgraded to System z9 or later to have zEnterprise z196 and z114
servers supported in the sysplex. If you have any z/OS images or coupling facility images on an earlier
server, and you intend to introduce a zEnterprise z196 and z114 server into that sysplex,
you must migrate those images to System z9 (or
later) server before introducing the zEnterprise z196 and z114 server.</li>
<li>The Integrated Cluster Bus 4 (ICB-4) Coupling Links are
not supported on a zEnterprise CPC.
Use 12x InfiniBand coupling links, which are designed to replace Integrated
Cluster Bus 4 (ICB-4), and to complement 1x InfiniBand and
ISC-3 on a zEnterprise server.
InfiniBand coupling can provide significantly improved service times
compared to ISC-3s for distances up to 150 meters. You can
read about InfiniBand coupling links in <em>IBM System z Connectivity Handbook</em> (SG24-5444).</li>
<li>The zEnterprise servers <strong>cannot</strong> be connected to a Sysplex Timer (9037-002). The Server Time
Protocol (STP) feature is the follow-on to the Sysplex Timer. STP is
designed to allow multiple servers and coupling facilities to maintain
time synchronization with each other without requiring a Sysplex Timer. STP is
a hardware feature of the zEnterprise, z10 EC, z10 BC, z9 EC, z9 BC,
z990, and z890 servers. To implement STP, see the STP web site and
the publications and other resources listed there. The STP web site
is at <a href="http://www.ibm.com/systems/z/advantages/pso/stp.html">http://www.ibm.com/systems/z/advantages/pso/stp.html </a>.
<p>The
STP design introduced a concept called Coordinated Timing Network
(CTN). A CTN is a collection of servers and coupling facilities that
are time-synchronized to a time value called Coordinated Server
Time. A CTN can be configured in two ways:</p>
<ul>
<li>STP-only CTN, which does not require a Sysplex Timer.</li>
<li>Mixed-CTN (External Time Reference and STP), which does
require a Sysplex Timer.
<p>The Sysplex Timer provides
the timekeeping information in a Mixed-CTN. Even though the zEnterprise servers do not
support attachment to a Sysplex
Timer, they can participate in a Mixed-CTN that has either
a z10 or z9 server synchronized to the Sysplex Timer. This maintains
the capability for enterprises to concurrently migrate from an existing
External Time Reference (ETR) to a Mixed-CTN and from a Mixed-CTN
to an STP-only CTN.</p></li></ul></li></ul></li>
<li><strong>Unsupported hardware features:</strong> The following
hardware features that were available on System z10 (and some earlier) servers <strong>cannot</strong> be
ordered (and cannot be carried forward on an upgrade to a z114) server
with zEnterprise servers.
You must migrate to the newer technology available on zEnterprise servers.
<ul>
<li>FICON Express</li>
<li>FICON Express2</li>
<li>Crypto Express2</li>
<li>OSA-Express2 10 GbE LR</li></ul>
<p>The following hardware features are not orderable
on z196 servers. If they are installed on your existing server at
the time of an upgrade to a z196 server, they may be retained.</p>
<ul>
<li>FICON Express4 10KM LX</li>
<li>FICON Express4 SX</li>
<li>FICON Express4 4KM LX</li>
<li>OSA-Express2 GbE LX</li>
<li>OSA-Express2 GbE SX</li>
<li>OSA-Express2 1000BASE-T</li></ul>
<p>The following hardware features are not orderable
on z114 servers. If they are installed on your existing server at
the time of an upgrade to a z114 server, they may be retained.</p>
<ul>
<li>FICON Express4 10KM LX</li>
<li>FICON Express4 SX</li>
<li>FICON Express4 4KM LX</li>
<li>FICON Express4-2C 4KM
LX</li>
<li>FICON Express4-2C SX</li>
<li>OSA-Express2 GbE LX</li>
<li>OSA-Express2 GbE SX</li>
<li>OSA-Express2 1000BASE-T</li></ul></li></ol>
<h3 id="znextbef">Actions you can take before you order a z196 and z114 server</h3>
<p>You can perform the following migration actions before you order
or install a zEnterprise server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in
which the zEnterprise server
will participate.</strong> See <a href="#znextres">Restrictions for a z196 or z114 server</a> for a description
of the limitations when using IBM zEnterprise zEC12 servers with zEnterprise z196 or z114
servers or with other earlier servers in a Parallel Sysplex.</li>
<li><strong>Implement STP (or a Mixed-CTN) timing
network.</strong> This action is necessitated because Sysplex Timers (9037-002)
are not supported on zEnterprise servers.
See <a href="#sttostp">Migrate from a Sysplex
Timer to STP</a>.</li>
<li><strong>Migrate from ICB-4 to InfiniBand coupling links.</strong> This
action is necessitated because ICB-4 links are not supported on zEnterprise servers. If desired,
you can take this action after you order a zEnterprise server, as you upgrade to the new server.
See <a href="#phoicb4">Migrate from ICB-4 to Infiniband coupling links</a>.</li>
<li><strong>Migrate from unsupported hardware features to
newer technology.</strong> This action is necessitated because FICON Express, FICON Express2,
Crypto Express2, and OSA-Express2 10 GbE LR are not supported on zEnterprise servers.</li>
<li><em></em><strong>Install the necessary z/OS service, as indicated in PSP
buckets.</strong> For a zEnterprise 196
CPC, PTFs are identified in the 2817DEVICE PSP bucket (Subset 2817/ZOS). <span>For a zEnterprise 114
CPC, PTFs are identified in the 2818DEVICE PSP bucket (Subset 2818/ZOS).</span> For
an IBM zEnterprise BladeCenter Extension
(zBX) attached to your z196 CPC or to your z114 CPC, the PTFs are
identified in the 2458DEVICE PSP bucket (Subset 2458/ZOS). In each
PSP bucket, the content is dependent on the z/OS release you will run on the zEnterprise server. If you
reviewed the PSP buckets some time ago, review them again to ensure
that any newly identified z/OS service
has been installed. To assist you in determining if you have the recommended
service (identified in these PSP buckets) installed on your system,
you can use the SMP/E REPORT MISSINGFIX command in conjunction with
the FIXCAT type of HOLDDATA, as follows:<a id="idx171"></a><a id="idx172"></a><a id="idx173"></a><a id="idx174"></a>
<ol type="a">
<li>Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s). Use your normal
service acquisition portals or download the two (2) year HOLDDATA
directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you select <strong>Full</strong> from the Download NOW
column (last 730 days) to receive the FIXCAT HOLDDATA, as the other
files do not contain FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify one or more of the following
Fix Categories (FIXCAT):
<ul>
<li>IBM.Device.Server.z196-2817</li>
<li>IBM.Device.Server.z196-2817.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z196-2817.ServerTimeProtocol</li>
<li>IBM.Device.Server.z196-2817.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z114-2818</li>
<li>IBM.Device.Server.z114-2818.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z114-2818.ServerTimeProtocol</li>
<li>IBM.Device.Server.z114-2818.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z114-2818.UnifiedResourceManager</li>
<li>IBM.Device.Server.zBX-2458</li>
<li>IBM.Device.Server.zBX-2458.ISAOPT</li></ul>
<p>The report will identify any missing coexistence and fallback
PTFs for that system. For complete information about the REPORT MISSINGFIX
command, see >SMP/E Commands</a>.</p></li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
PTFs recommended for the zEnterprise servers.</li></ol>
<div>
<div class="notelisttitle" id="wq103">Notes:</div>
<ol type="a">
<li>You can also use Service Link&rsquo;s PSP Service Extraction tool.</li>
<li>Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010,
you can no longer use that tool to identify missing PSP bucket service.
You should use SMP/E's Fix Category support, which is fully integrated
into SMP/E procedures and IBM product
and service deliverables.</li>
</ol></div></li>
<li><strong>Run CFSIZER.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on higher
CFCC levels than they were previously, run the Coupling Facility Structure
Sizer (CFSIZER) tool to find out if you have to increase coupling
facility structure sizes. zEnterprise servers
are initially shipped with <span>CFCC Level 18</span>; prepare
to make the necessary changes as indicated by the tool. You can find
the CFSIZER tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.</li>
<li><strong>Plan for the fixed HSA enhancement on a zEnterprise server.</strong> On zEnterprise (and z10) servers, preplanning requirements
are minimized by offering a fixed HSA and introduction of the ability
to seamlessly include such events as creation of LPARs, inclusion
of logical subsystems, changing logical processor definitions in an
LPAR, and introduction of cryptography into an LPAR.</li>
<li><strong id="icsfstp">Decide on the steps you will take
for your migration to a zEnterprise server.</strong> 
As a guide, see <a href="#znxtrmss">Recommended migration steps for z196 and z114 servers</a>. Also, note the following:
<ul>
<li>You should compare the cryptographic support you currently
have installed with the support required for the functions you plan
to use on the zEnterprise z196
and z114 server. Several cryptographic support web deliverables have
been made available for various z/OS releases.
When a subsequent cryptographic web deliverable is available for a
particular z/OS level, the
previous one is withdrawn. The newer cryptographic web deliverable,
however, includes the previous function (when applicable) for that
particular z/OS level. Note
that you can use the newer cryptographic web deliverables on servers
before the zEnterprise servers,
that is, on z10 and z9 (or earlier) servers.</li>
<li>The level of function provided for cryptographic support differs
by z/OS release and the ICSF
web deliverable that is installed.  For z/OS V1R11
and later, exploitation of zEnterprise z196
and z114 cryptographic support is provided by Cryptographic Support
for <span>z/OS V1R11-V1R13
(FMID HCR7790), web deliverable (the z/OS Lifecycle
Extension for z/OS V1.11 (5657-A01)
is required for support after September 2012)</span>.  Note that this
level of ICSF is <strong>not</strong> integrated in z/OS V1R13 and will need to be
downloaded and installed even after ordering a z/OS V1R13 ServerPac.  
<p>For z/OS V1R11 and z/OS V1R12,
exploitation of the original zEnterprise cryptographic
enhancements was provided by the Cryptographic Support for z/OS V1R10-V1R12 web deliverable
(FMID HCR7780), which is integrated into z/OS V1R13 orders. The Cryptographic web deliverables
are available at <a href="http://www.ibm.com/systems/z/os/zos/downloads/">http://www-03.ibm.com/systems/z/os/zos/downloads/</a></p>
<ul>
<li>Coexistence PTFs are available for all supported z/OS releases and all existing supported ICSF web
deliverables.</li>
<li>For z/OS V1R11: If you
require protected key CP Assist for Cryptographic Function, new Crypto
Express3 or Crypto Express3 -1P, then minimally you must install the
Cryptographic Support for z/OS V1R9-V1R11
web deliverable (FMID HCR7770).</li>
<li>For z/OS V1R11 and z/OS V1R12: If you require ANSI
X9.8 Pin security, enhanced Common Cryptographic Architecture (CCA),
64 Bit, CP Assist for Cryptographic Function (CPACF) enhancements,
Secure Keyed-Hash Message Authentication Code (HMAC), CKDS Constraint
Relief, PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature
Algorithm, and CBC Key Wrap, PKA RSA OEAP with SHA-256, then minimally
you must install the Cryptographic Support for z/OS V1R10-V1R12 web deliverable (FMID HCR7780),
which is integrated into z/OS V1R13
orders.</li>
<li>For z/OS V1R11
and later releases: For Crypto Express3 feature when defined as a
coprocessor: expanded support for AES algorithm, enhanced ANSI TR-31
Secure Key Exchange, PIN block decimalization table protection, and
PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve Cryptography
(ECC) functions. You must install the Cryptographic Support for z/OS V1R11-V1R13 web deliverable
(FMID HCR7790), available September 2011.</li></ul>
<div>
<div class="notetitle" id="wq105">Note:</div>
<div class="notebody"> ICSF, specifically HCR7770, HCR7780, <span>and
HCR7790</span>, require coexistence PTFs to be installed on earlier
levels of ICSF if they share keys in their sysplex. To assist in identifying
the coexistence service, the following Fix Categories can be used: 
<ul>
<li>IBM.Coexistence.ICSF.z/OS_V1R9-V1R11-HCR7770</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790</li></ul></div></div></li></ul></li>
<li><strong>Review the new mnemonics introduced for the zEnterprise server.</strong> The
new mnemonics might collide with (be identical to) the names of assembler
macro instructions you use or provide. In the event of such collisions,
the HLASM's default opcode table (UNI) will treat specification
of these names as instructions when APAR PM49761 is installed.  This
will probably cause assembler error messages and possibly cause generation
of incorrect object code. 
<p>If you write programs in Assembler Language,
you should compare the list provided in <cite>z/Architecture Principles
of Operation</cite>, SA22-7832,
to the names of assembler macro instructions you use or provide, to
identify any such conflicts or collisions that would occur following
installation of HLASM APAR PM49761. If a conflict is identified, take
one of the following actions:</p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify PARM='...OPTABLE(YOP)...' (or
some other earlier opcode table).</li>
<li>Specify a separate ASMAOPT file containing assembler options,
such as in the previous method (this method requires no changes to
source code or JCL).</li>
<li>Add, as the first statement of your source program, *PROCESS OPTABLE(YOP).</li>
<li>Specify the PROFILE option either in JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the front of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique (where XXX
is a sample mnemonic):
<pre class="xmp"><code>Assume the default OPTABLE(UNI) is in effect
			XXX   a,b       new instruction
			PUSH  ACONTROL  save current optable definition
			ACONTROL OPTABLE(YOP)   switch optable dynamically
			XXX   r,s,t     macro invocation
			POP   ACONTROL  restore previous definition
			XXX   c,d       new instruction</code></pre></li></ul>
<p>For more information about HLASM's opcode table,
see >HLASM Programmer&rsquo;s Guide</a>.</p></li></ol>
<h3 id="znextaft">Actions you can take after you order a z196 and z114 server</h3>
<p>After you order but before you install your zEnterprise server, do the
following:</p>
<ol type="1">
<li><strong>Use the CHPID Mapping Tool.</strong> As you might
have done with your z10 EC, z10 BC, z9 EC
or z9 BC servers, use the CHPID
Mapping Tool to map logical CHPIDs to physical channels (PCHIDs) and
create input to HCD/IOCP for your zEnterprise server.
The tool is a workstation-based Java application
available from the Resource Link&reg; web site (<a href="http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).
For more information about this tool, refer to the web site.</li>
<li><strong>Define an Ensemble.</strong> If you are running z/OS V1R10 or later, you can define
an Ensemble and exploit the IBM zEnterprise Unified Resource
Manager. See <em>System
z Ensemble Planning and Configuration Guide</em> (GC27-2608)
for a detailed description of the steps required to define an Ensemble.</li></ol>
<h3 id="znxtrmss">Recommended migration steps for z196 and z114 servers</h3>
<p>This topic suggests the steps for migrating your same z/OS release level from your current
server to a zEnterprise server.
The steps are based on the assumption that you want to minimize the
amount of change (and therefore risk) and the amount of work required
to perform the migration.</p>
<p>Your migration steps follow:</p>
<ol type="1">
<li>If necessary, migrate to an STP-only or Mixed-CTN
timing network.</li>
<li>Ensure that you have installed the z196, z114, z10 EC (or z10 BC),
and z9 EC (or z9 BC) required service, as indicated in the respective
PSP buckets. See <strong>Install the necessary z/OS service, as indicated in PSP
buckets</strong> in <a href="#znextbef">Actions you can take before you order a z196 and z114 server</a> for information about how
SMP/E V3R5 and SMP/E V3R6 can help you identify, acquire, and install
any missing required service.</li>
<li>Ensure you have the required service, and any required ICSF web
deliverable installed for the cryptographic functions that you have
decided to use.</li>
<li>Upgrade your hardware to zEnterprise system.
If necessary convert to InfiniBand Coupling Links from ICB-4 links.</li>
<li>Update configuration setting to exploit zEnterprise functions.</li></ol>
<h3 id="znextexp">Migration and exploitation considerations for z196 and z114
server functions</h3>
<p>This topic provides migration and exploitation considerations for zEnterprise server functions.</p>
<p>The following zEnterprise functions
are available on z/OS V1R11
and later releases:</p>
<ul>
<li><strong>InfiniBand Coupling.</strong>  Each system can use,
or not use, InfiniBand coupling links independently of what other
systems are doing, and do so in conjunction with other link types.
InfiniBand Coupling connectivity can only be performed with other
systems that also support InfiniBand Coupling.</li>
<li><strong>HiperDispatch.</strong>  The existing HIPERDISPATCH=YES|NO
parameter in IEAOPT<var class="pv">xx</var> member of parmlib, and on the SET OPT=<var class="pv">xx</var> command
to control whether HiperDispatch is enabled or disabled for the system,
can be changed dynamically.  The default is that HiperDispatch is
disabled on z/OS V1R7 through z/OS V1R12. 
<p>Beginning
with z/OS V1R13 when running
on a zEnterprise server,
the IEAOPT<var class="pv">xx</var> keyword HIPERDISPATCH will default to YES. If
HIPERDISPATCH=NO is specified, the specification will be honored as
it was on previous z/OS releases.
The IBM z/OS Health Checker check SUP_HiperDispatch checks
whether the expected HiperDispatch check parameter state (HIPERDISPATCH(YES)
or HIPERDISPATCH(NO), where YES is the default for the check, matches
the actual HiperDispatch state of the system. For more information,
see <a href="#hyperz196">Accommodate HiperDispatch default of YES on IBM zEnterprise zEC12 and IBM zEnterprise (z196 and z114)</a> .</p>
<p>A WLM goal adjustment might be
required when using HiperDispatch. Review and update your WLM policies
as necessary.</p></li>
<li><strong>HiperDispatch cache and affinity node changes.</strong> This
function is enhanced to exploit zEnterprise architecture
and now allows three physical CPs from same chip to form affinity
node. A z10 uses HiperDispatch
book cache support and four physical CPs from same book.
<p>To realize
the benefits of HiperDispatch, z/OS has
been changed to force HiperDispatch=YES for LPARs with greater than
64 CPUs. On LPARs with greater than 64 CPUs defined on a zEnterprise server with IEAOPT<var class="pv">xx</var> specifying
HIPERDISPATCH=NO during IPL (or SET OPT=<var class="pv">xx</var> after IPL), the
system generates a message but continues to run with HIPERDISPATCH=YES.
The new message is IRA865I HIPERDISPATCH=YES FORCED DUE TO GREATER
THAN 64 LPS DEFINED.</p>
<p>On LPARs in which HIPERDISPATCH=NO is specified
with less than 64 CPUs, you can dynamically add more CPUs and continue
to run in HIPERDISPATCH=NO. However, you may see the new message ISN012E
HIPERDISPATCH MUST BE ENABLED TO CONFIGURE CPU IDS GREATER THAN 3F
ONLINE.</p>
<p>Any attempt to configure CPUs greater than 64 CPUs online
in HIPERDISPATCH=NO will be rejected with message IEE241I CPU(x) NOT
RECONFIGURED ONLINE - REQUIRES HIPERDISPATCH ENABLED.</p>
<p>An LPAR
with greater than 64 CPUs that dynamically changed to HIPERDISPATCH=YES
cannot go back to HIPERDISPATCH=NO.  It will be treated as if it was
IPLed with HIPERDISPATCH=YES after HIPERDISPATCH=YES is activated.</p>
<p>To
assist with warning when you are getting close to 64 CPUs and running
with HIPERDISPATCH=NO, the IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig,
was added in z/OS V1R12 and
available on z/OS V1R11 with
APAR OA30476. The check always succeeds for LPAR in HIPERDISPATCH=YES
(all CPU configurations supported). When an LPAR is running with HIPERDISPATCH=NO,
the check raises an exception when the number of CPUs is close to
forcing the LPAR to IPL with HIPERDISPATCH=YES. The CPUSLEFTB4NEEDHD
parameter indicates the minimum number of CPUs that can be installed
and activated on an LPAR running in HIPERDISPATCH=NO. When CPUSLEFTB4NEEDHD=0,
the check always succeeds. The default is 8, with values 0-63 accepted.
The system redrives the check when the HIPERDISPATCH state changes
or CPUs are dynamically added. Possible IBM Health
Checker for z/OS messages:</p>
<ul>
<li>IEAVEH080I CPU configuration supported with HiperDispatch <var class="pv">curstate</var></li>
<li>IEAVEH081E CPU configuration supported with HiperDispatch disabled. <var class="pv">numcpus</var> more
CPU(s) can be added with HiperDispatch disabled.</li></ul></li>
<li><strong>CFCC Level 17.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on higher
CFCC levels than they were previously, run the Coupling Facility Structure
Sizer (CFSIZER) tool to find out if you have to increase coupling
facility structure sizes. zEnterprise servers
initially shipped with CFCC Level 17. Prepare to make the necessary
changes as indicated by the tool. You can find the CFSIZER tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.
<div>
<div class="notetitle" id="wq108">Note:</div>
<div class="notebody">The PTFs to support
CFCC Level 17 have coexistence (or sysplex preconditioning) PTFs that
require installation throughout your sysplex prior to implementing
CFCC Level 17.</div></div></li>
<li><strong>Third Subchannel Set.</strong> You now have the ability
to extend the amount of addressable storage capacity to help facilitate
storage growth with the introduction of a third subchannel set, an
additional 64K devices, to help complement other functions such as
"large" or extended addressing volumes and HyperPAV. This may also
help to facilitate consistent device address definitions, simplifying
addressing schemes for congruous devices.
<p>The first subchannel set
(SS 0) allows definitions of any type of device, such as bases, aliases,
secondaries, and those other than disk that do not implement the concept
of associated aliases or secondaries. The second and third subchannel
sets (SS1 and SS2) can now both be designated for use for disk alias
devices (of both primary and secondary devices), or Metro Mirror secondary
devices only. The third subchannel set applies ESCON, FICON and
zHPF protocols. Definitions for the third subchannel set are similar
to those for the second subchannel set and can be made with HCD.</p>
<p>The IODF statement of LOAD<var class="pv">xx</var> allows users to indicate which
devices to use during IPL (that is, devices that are connected to
subchannel set 0, 1 or 2). This specification is done on the IODF
statement (column 36).  For more information, see >z/OS MVS Initialization and Tuning Reference</a>.</p></li>
<li><strong>IPL from alternate subchannel set.</strong> This
function allows you to IPL from subchannel set 1 (SS1) or subchannel
set 2 (SS2), in addition to subchannel set 0. Devices used early during
IPL processing can now be accessed using subchannel set 1 or subchannel
set 2. This is intended to allow users of Metro Mirror (PPRC) secondary
devices defined using the same device number and a new device type
in an alternate subchannel set to be used for IPL, IODF, and standalone
dump volumes when needed. IPL from an alternate subchannel set
is supported by z/OS V1R13,
as well as z/OS V1R12 and z/OS V1R11 with PTFs, and applies
to the FICON and zHPF protocols
(CHPID type FC).
<p>To IPL from an alternate subchannel set, you
need to specify a 5 digit load address on the LPAR image profile on
the HMC, and have the appropriate specification on the IODF statement
(column 36) in LOAD<var class="pv">xx</var>.</p></li>
<li> <strong>IBM zEnterprise Unified Resource
Manager for enabling management and virtualization of heterogeneous
workloads.</strong> The Unified Resource Manager manages the deployment
of heterogeneous hardware resources based on individual workload requirements:
<ul>
<li>Performance management</li>
<li>Integrated private data network</li></ul>  See <em>System
z Ensemble Planning and Configuration Guide</em> (GC27-2608)
 for a detailed description on the steps required.</li>
<li><strong>Power save
mode. </strong> This function is available only on zEC12 and z196 servers.
There is a new SMFPRM<var class="pv">xx</var> parmlib option, MAXEVENTINTRECS,
that allows governing the number of event interval records to be collected
when the processor capacity changes. The default is zero. To collect
extra records between regular intervals when the processor capacity
changes, the default must be adjusted.
<p>If you are using the CPU
Measurement Facility (Hardware Instrumentation Services), there is
a new parameter on the MODIFY <var class="pv">hisproc</var> command. You can use
this parameter, STATECHANGE, to override the default action to take
when a CPU speed change is detected within the HIS component.</p></li>
<li><strong>zHPF performance improvements for FICON Express8S.</strong> FICON Express8S contains a new IBM ASIC which is designed to support
the 8 Gbps (gigabytes per second) PCIe interface to the PCIe I/O drawer
and increased start I/Os. In addition, a hardware data router has
been added in support of the zHPF and FCP protocols for path length
reduction and increased throughput. FICON Express8S
supports a link data rate of 2, 4, or 8 Gbps autonegotiated. With
these changes FICON Express8S,
when supporting the zHPF or FCP protocols, has been designed to achieve
full duplex line speed (8 Gbps) in each direction. The performance
of the FICON protocol remains
unchanged from FICON Express8.
To use zHPF performance improvements for FICON Express8S, you need to specify the <span class="pk">ZHPF=YES
| NO</span> parameter in the IECIOS<var class="pv">xx</var> of PARMLIB and use FICON Express8S</li>
<li><strong>Additional Crypto exploitation.</strong> The following
enhancements have been added to the Common Cryptographic Architecture
support, which is used in the Crypto Express3 feature when it is configured
as a coprocessor: 
<ul>
<li>ANSI X9.8 Pin security</li>
<li>Enhanced Common Cryptographic Architecture (CCA), 64bit, CP Assist
for Cryptographic Function (CPACF) enhancements</li>
<li>Secure Keyed-Hash Message Authentication Code (HMAC)</li>
<li>CKDS Constraint Relief</li>
<li>PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature
Algorithm</li>
<li>CBC Key Wrap</li>
<li>PKA RSA OEAP with SHA-256</li>
<li>Expanded support for AES algorithm</li>
<li>Enhanced ANSI TR-31 Secure Key Exchange</li>
<li>PIN block decimalization table protection</li>
<li>PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
Cryptography (ECC) functions.</li></ul></li></ul>
<p>The following zEnterprise functions
are only available on z/OS V1R12
and later releases:</p>
<ul>
<li><strong>z/OS Discovery
and AutoConfiguration (zDAC) for FICON channels.</strong> With
a zEnterprise CPC and z/OS, a new function, z/OS Discovery and AutoConfiguration
(zDAC), is designed to automatically perform a number of I/O configuration
definition tasks for new and changed disk and tape controllers connected
to a switch or director when attached to a FICON channel. When new controllers are added to
an I/O configuration, or changes are made to existing controllers,
the system is designed to discover them and propose configuration
changes based on a policy you define in the hardware configuration
dialog (HCD). Your policy can include preferences for availability
and bandwidth including parallel access volume (PAV) definitions,
control unit numbers, and device number ranges.
<p>zDAC is designed
to perform discovery for all systems in a sysplex that support the
function. The proposed configuration will incorporate the current
contents of the I/O definition file (IODF) with additions for newly
installed and changed control units and devices. zDAC is designed
to help simplify I/O configuration on CPC running z/OS and reduce complexity and setup time. zDAC
applies to all FICON features
supported on zEnterprise servers
when configured as CHPID type FC, and is supported by z/OS V1R12 and later.</p>
<p>To
use zDAC, you must first establish a policy for the discovery operation.
This is done through HCD or HCM. You can limit the scope of the discovery,
limit the proposal information, indicate the desired number of paths
to discovered logical control units, and indicate the method used
for device and control unit numbering. After controllers and devices
are discovered, you can select which controllers to be defined and
accept or override the proposed values for control units and devices.</p></li>
<li><strong>OSA-Express3 and OSA-Express4S Inbound
Workload Queuing (IWQ).</strong>  Inbound workload queuing for Enterprise
Extender is supported by the OSA-Express4S and OSA-Express3 features
when defined as CHPID types OSD or OSX. It is exclusive to the z196
and z114 servers, and is supported by z/OS and
by z/VM&reg; for guest exploitation.
OSA-Express3 introduces inbound workload queuing (IWQ), which creates
multiple input queues and allows OSA to differentiate workloads "off
the wire" and then assign work to a specific input queue (per device)
to z/OS. With each input queue
representing a unique type of workload, each having unique service
and processing requirements, the IWQ function allows z/OS to preassign the appropriate processing resources
for each input queue. This approach allows multiple concurrent z/OS processing threads to then
process each unique input queue (workload), avoiding traditional resource
contention. In a heavily mixed workload environment, this "off the
wire" network traffic separation provided by OSA-Express3 IWQ reduces
the conventional z/OS processing
required to identify and separate unique workloads, which results
in improved overall system performance and scalability. The types
of z/OS workloads that are
identified and assigned to unique input queues are:
<ul>
<li>z/OS Sysplex Distributor
traffic: Network traffic that is associated with a distributed Virtual
Internet Protocol Address (VIPA) is assigned a unique input queue
allowing the Sysplex Distributor traffic to be immediately distributed
to the target host.</li>
<li>z/OS bulk data traffic:
Network traffic that is dynamically associated with a streaming (bulk
data) TCP connection is assigned to a unique input queue allowing
the bulk data processing to be assigned the appropriate resources
and isolated from critical interactive workloads.</li></ul>
<p>IWQ is supported on zEnterprise CPC
and System z10, and is exclusive
to OSA-Express3 CHPID types OSD and OSX (exclusive to zEnterprise CPC). There are
some Communications Server configuration settings required to enable
multiple inbound data queues.</p></li>
<li><strong>Display OSAINFO.</strong> OSA-Express3 introduces
the capability for the operating system to directly query and display
the current OSA configuration information (similar to OSA/SF). z/OS exploits this new OSA capability
by introducing a new TCP/IP operator command, Display OSAINFO. Display
OSAINFO allows the operator to monitor and verify the current OSA
configuration, which helps to improve the overall management, serviceability,
and usability of OSA-Express3. The Display OSAINFO command is exclusive
to OSA-Express3 CHPID types OSD, OSM, and OSX (on z196, z114, and z10 servers).</li>
<li><strong>C/C++ ARCH(9) and TUNE(9) options.</strong> The ARCHITECTURE
XL C/C++ compiler option selects the minimum level of machine architecture
on which your program can run. Certain features provided by the compiler
require a minimum architecture level. ARCH(9) exploits instructions
available on zEnterprise servers.
The TUNE compiler option allows you to optimize your application for
specific machine architecture. The TUNE level has to be at the ARCH
level, at a minimum. If the TUNE level is lower than the specified
ARCH level, the compiler forces TUNE to match the ARCH level, or uses
the default TUNE level, whichever is greater. For more information
about the ARCHITECTURE XL and TUNE compiler options, see >z/OS XL C/C++ User&rsquo;s Guide</a>. 
<p><strong>Exploitation restriction.</strong> When programs exploit
the ARCH(9) or TUNE(9) option, those programs can only run on zEnterprise servers, or an
operation exception will occur. This is a consideration for programs
that will run on different server levels (z10 and z9 servers) during development, test,
and production, as well as during fallback or disaster recovery.</p>
<p>For
example, the XL C/C++ ARCH(10) and TUNE(10) option exploits instructions
available only on a zEC12 server. When programs exploit the ARCH(10)
or TUNE(10) option, those programs can only run on a zEC12 server,
or an operation exception will occur.</p></li></ul>
<p>The following zEnterprise functions
are only available on z/OS V1R13
and later releases. See >z/OS Introduction and Release Guide</a> 
for restrictions, dependencies, and steps to take to use these new
hardware functions):</p>
<ul>
<li><strong>OSA-Express4S checksum offload for LPAR-to-LPAR
traffic for IPv4 and IPv6 packets (CHPID type OSD).</strong> Checksum
offload for LPAR-to-LPAR traffic is included in the OSA-Express4S
design. The checksum function has been moved from the PCIe adapter
to the OSA-Express4S hardware to help reduce CPU utilization.</li>
<li><strong> OSA-Express4S large send for IPv6 packets (CHPID
types OSD and OSX).</strong> Large send (also referred to as TCP segmentation
offload) is designed to improve performance by offloading outbound
TCP segmentation processing from the host to an OSA-Express4S feature
by employing a more efficient memory transfer into OSA-Express4. Large
send support for IPv6 packets applies to the OSA-Express4S features
(CHPID type OSD and OSX), and is exclusive to zEC12, z196, and z114.</li>
<li><strong>Inbound workload queuing for Enterprise Extender.</strong> Inbound
workload queuing (IWQ) for the OSA-Express4S features has been enhanced
to differentiate and separate inbound Enterprise Extender traffic
to a new input queue. The Enterprise Extender separation and processing
associated with the Enterprise Extender input queue provides improved
scalability and performance for Enterprise Extender.</li></ul>
<div>
<div class="notetitle" id="wq109">Note:</div>
<div class="notebody">  See >z/OS Communications Server: IP Configuration Guide</a> for
additional information about OSA-Express4S checksum offload for LPAR-to-LPAR
traffic for IPv4 and IPv6 packets (CHPID type OSD), OSA-Express4S
large send for IPv6 packets (CHPID types OSD and OSX), and Inbound
workload queuing for Enterprise Extender.</div></div>
<h3 id="znextsod">Accommodate functions for the z196 and z114 servers to be discontinued
on future servers</h3>
<p><strong>Description:</strong> The following changes in hardware
support could affect your environment. Make appropriate changes as
needed.</p>
<ul>
<li><strong>ISC-3 features (#0217, #0218, #0219).</strong> The IBM zEnterprise zEC12 is planned to be the last high-end System z server to offer support
of the InterSystem Channel-3 (ISC-3) for Parallel Sysplex environments at extended distances.
ISC-3 will not be supported on future high-end System z servers as carry forward on an upgrade.
Previously it was announced that the IBM zEnterprise 196 (z196) and IBM zEnterprise 114 (z114) servers were the last to offer
ordering of ISC-3. Enterprises should continue migrating from ISC-3
features (#0217, #0218, #0219) to 12x InfiniBand (#0171 - HCA3-O fanout)
or 1x InfiniBand (#0170 - HCA3-O LR fanout) coupling links.</li>
<li><strong>Power Sequence
Controller (PSC feature #6501).</strong> 
 The last zEnterprise server
machines to support PSC (feature #6501) are the z196 (machine type
2817) and z114 (machine type 2818). PSC features cannot be ordered
and cannot be carried forward on an upgrade to the zEC12 server. The
optional PSC feature is used to turn on or off specific control units
from the central processor complex (CPC).</li>
<li><strong>ESCON channels.</strong> The
last zEnterprise server
to support ESCON channels
are the z196 (machine type 2817)  and z114 (machine type 2818). In
addition, ESCON channels cannot
be carried forward on an upgrade to the zEC12 server. This applies
to channel path identifier (CHPID) types CNC, CTC, CVC, and CBY and
to feature numbers 2323 and 2324. You should be migrating from ESCON to FICON and eliminating ESCON channels from the mainframe wherever possible.
Alternate solutions are available for connectivity to ESCON devices. IBM Global Technology Services offers an ESCON to FICON migration solution, Offering ID #6948-97D,
to help facilitate migration from ESCON to FICON. This offering can help
you to simplify and manage a single physical and operational environment.</li>
<li><strong>OSA-Express2 features.</strong> The z196 is the last
high-end server, and the z114 is the last mid-range server,
to support OSA-Express2 features. OSA-Express2 features are
not supported on future servers. You should begin migrating from OSA-Express2
features (#3364, #3365, #3366) to OSA-Express3 1000BaseT and
OSA-Express4S features.</li>
<li><strong>Dial-up modems.</strong> The z196 is the last high-end
server, and the z114 is the last mid-range server, to support
dial-up modems for use with the Remote Support Facility (RSF), and
the External Time Source (ETS) option of Server Time Protocol (STP).
These features are not supported on future servers. The currently
available Network Time Protocol (NTP) server option for ETS, as well
as Internet time services available using broadband connections, can
be used to provide the same degree of accuracy as dial-up time services.
You should begin migrating from dial-up modems to broadband for RSF
connections.</li></ul>
<div>
<div class="notetitle" id="wq110">Note:</div>
<div class="notebody">IBM's statements regarding its plans, directions,
and intent are subject to change or withdrawal without notice at IBM's
sole discretion. Information regarding potential future products is
intended to outline our general product direction and it should not
be relied on in making a purchasing decision. The information mentioned
regarding potential future products is not a commitment, promise,
or legal obligation to deliver any material, code, or functionality.
Information about potential future products may not be incorporated
into any contract. The development, release, and timing of any future
features or functionality described for our products remains at our
sole discretion</div></div>
<table id="wq111" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>12 July 2011 in U.S. Announcement Letter 211-252.</li>
<li>15 February 2011 in U.S. Announcement Letter 111-012.</li>
<li>22 July 2010 in U.S. Announcement letter 110-170.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before migrating to a zEnterprise server.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes if you are using a zEC12 server because
these servers do not support the functions mentioned in "Description"
above.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>See &quot;Description&quot; above.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Take into account the statements
in &quot;Description&quot; above as you make your plans for the future.</p>
<p><strong>Reference information:</strong> None.</p>
<h2 id="migrz10">Migrate to a System z10 server</h2>
<p><strong>Description:</strong> The IBM System z10 servers
(z10 EC and z10 BC) are follow ons to the IBM System z9 servers
(z9 EC [formerly z9-109] and z9 BC) and IBM eServer zSeries servers (z990, z890,
z900, and z800). The System z10 servers
build on the inherent strengths of the System z platform, deliver new technologies that
offer dramatic improvements in price and performance for key new workloads,
and enable a new range of hybrid solutions.</p><a id="idx175"></a><a id="idx176"></a><a id="idx177"></a><a id="idx178"></a><a id="idx179"></a><a id="idx180"></a><a id="idx181"></a><a id="idx182"></a>
<p>The specific System z10 functions
exploited by z/OS depend on
the z/OS release. See <a href="#z10func">Table 7</a>.</p>
<table id="z10func" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 7. System z10 functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq112" width="37%" align="left">System z10 function</th>
<th id="wq113" width="20%" align="left">R11</th>
<th id="wq114" width="20%" align="left">R12</th>
<th id="wq115" width="20%" align="left">R13</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td colspan="3" align="center" headers="wq112 wq113 wq114"><strong>Included in base z/OS support</strong></td>
<td align="center" headers="wq115"></td>
</tr>
<tr>
<td headers="wq112">Dynamic addition of logical CPs without preplanning</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">RMF FICON enhancement</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Greater than 54 CPs (64) for a single LPAR</td>
<td headers="wq113">B (z10 EC
only)</td>
<td headers="wq114">B (z10 EC
only)</td>
<td headers="wq115">B (z10 EC
only)</td>
</tr>
<tr>
<td headers="wq112">XL C/C++ ARCH(8) and TUNE(8)</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Large memory (up to 1 TB on z10 EC now, up to 248 GB on z10 BC planned for 30Jun2009)</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">HiperDispatch</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">CPACF and Configurable Crypto Express2</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Key management for remote loading of ATM and
point-of-sale (POS) keys and support for ISO 16609 CBC
Mode T-DES MAC requirements</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">New z/Architecture instructions</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">65535 MP factors</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">OSA-Express3 10 Gigabit Ethernet</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">FICON8 enhancement</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">OSA-Express3 Gigabit Ethernet</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">1000BASE-T Ethernet</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Protected Key CP Assist for Cryptographic Function</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">New Crypto Express3 and Crypto Express3 -1P</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td colspan="3" align="center" headers="wq112 wq113 wq114"><strong>Explicit z/OS support</strong></td>
<td align="center" headers="wq115"></td>
</tr>
<tr>
<td headers="wq112">HiperSockets Multiple
Write Facility</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Capacity Provisioning</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Large page support</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">OSA-Express3 double port density</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">CPU Measurement Facility architecture</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Service aids support for large dumps</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Layer 3 VMAC support (VMAC Support for OSA-Express2
and OSA-Express3 when configured as CHPID type OSD [QDIO])</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">CPACF enhanced to support SHA-384 and SHA-512
bit for message digest, ISO Format 3 PIN blocks, secure key AES, support
for RSA keys up to 4096 bits in length, dynamically add crypto to
a logical partition, Random Number Generator Long, and enhanced TKE
auditing</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Support for 13-digit through 19-digit PAN data,
ICSF Query service, and enhanced SAF checking</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Coupling facility level 16</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">High Performance FICON for System z (zHPF)</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Decimal floating point</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Usage Report Program (IFAURP) support</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td headers="wq112">Parallel
Sysplex InfiniBand (PSIFB) coupling links</td>
<td headers="wq113">B</td>
<td headers="wq114">B</td>
<td headers="wq115">B</td>
</tr>
<tr>
<td colspan="3" headers="wq112 wq113 wq114"><strong>Legend:</strong>
<ul class="simple">
<li>Blank - not supported</li>
<li>B - FMID in base product (assumes service identified in
the hardware PSP bucket is installed)</li>
<li>P - PTFs listed in the System z10 PSP
bucket are required</li></ul></td>
<td headers="wq115"></td>
</tr>
</tbody>
</table>
<table id="wq116" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The System z10 EC
server, which first shipped in February 2008.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS on a System z10 server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>A System z10 server.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>See the appropriate PSP buckets for required
web deliverables and PTFs for specific functions, as described in <a href="#z10rmss">Recommended migration steps for a System z10 server</a>.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>See the appropriate PSP buckets for required
PTFs for specific functions, as described in <a href="#z10rmss">Recommended migration steps for a System z10 server</a>.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the recommendations
and considerations, adhere to the restrictions, and perform the tasks
described in the topics below.</p>
<h3 id="wq117">General recommendations and considerations for a System z10 server</h3>
<p>As you plan your migration to a System z10 server,
consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when
coming from a System z9 server.</strong> Migration
to a System z10 server has, as
its basis, a migration to a z9 EC
or z9 BC. This means that if
you are migrating to a System z10 server
from a z9 EC or z9 BC (and have performed the migration actions
associated with the z9 EC or z9 BC), you have fewer migration
actions than if you were migrating from a server prior to the z9 EC or z9 BC
and have not yet performed the migration actions associated with the z9 EC or z9 BC.
There are, in fact, very few new migration actions to perform on z/OS for a System z10 server if you have already migrated to a z9 EC or z9 BC.
It is important to note that you can migrate directly to a System z10 server without installing the
intermediate (prior to z9 EC
and z9 BC) servers, but you still
need to ensure that any migration considerations are satisfied for
the servers that you &quot;skipped&quot;. To read about z9 EC and z9 BC
migration actions, see <a href="#mtodanu">Migrate to a System z9 server</a>.</li>
<li><strong>Support is delivered by service (and FMID web
deliverables for ICSF).</strong> The delta (from a z9 EC or z9 BC)
support for a System z10 server,
excluding cryptographic support, is delivered by service (PTFs). 
Some cryptographic support for the System z10 (and
earlier) servers is provided by a web deliverable (FMID). Depending
on the cryptographic support provided and the z/OS release that you are running, you might need
to download and install a different ICSF web deliverable.</li>
<li><strong>Larger coupling facility structure sizes might
be necessary.</strong> When you change coupling facility control code
(CFCC) levels, your coupling facility structure sizes might change.
System z10 servers now ship with
CFCC level 16. If, as part of your migration to a System z10 server, you change CFCC levels
(either by placing a coupling facility on the System z10 server or by moving the coupling facility to
a z9 EC or z9 BC at a later CFCC level), you might have larger
structure sizes than you did previously. If your CFCC levels are identical,
structure sizes are not expected to change when you migrate from a
previous server to a System z10 server.</li>
<li><strong>Update CFRM policies.</strong> Coupling facilities
are identified in the CFRM policy by their physical node descriptor
information (for example, machine type, model, serial number, LPAR
number). When a coupling facility undergoes a hardware upgrade, one
or more of these pieces of information is likely to change, therefore,
the definition of the coupling facility in the CFRM policy must change
accordingly.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To
minimize the amount of change (and therefore risk) that you experience
at one time, do not migrate your software release level at the same
time that you migrate your hardware.</li></ol>
<h3 id="wq119">Restrictions for a System z10 server</h3>
<p>Restrictions associated with the System z10 server are:</p>
<ol type="1">
<li><strong>Functional limitations:</strong> Not all System z10 functions are available in every z/OS release. See <a href="#z10func">Table 7</a> for a list of the System z10 functions
available in each z/OS release.
Some functions have exploitation or migration considerations (see
below).  Many functions are enabled or disabled, based on the presence
or absence of the required hardware and software. If you wish to position
to exploit any new System z10 functions,
the software and hardware may be installed in either order. That is,
there is no requirement to install either software or hardware first
to exploit a specific function.</li>
<li><strong>System z10 in
a sysplex:</strong> 
<ul>
<li>The z9 EC and z9 BC are the last servers to support active participation
in the same Parallel
Sysplex with z900, z800, and earlier servers.  If you are running z/OS on a z900 or z800, you cannot
add a System z10 server to that
sysplex. That is, you will not be able to perform rolling IPLs to
introduce a System z10 server
if you have any z900 or z800 images (either as z/OS images or coupling facilities) in the sysplex.
Any z900 or z800 servers in the sysplex have to be upgraded to a z990,
z890, or later server to have a System z10 server
supported in the sysplex.  If you have any z/OS images or coupling facilities on a z900 or
z800, and you intend to introduce a System z10 server into that sysplex, you must migrate those
images to z990 or z890 (or later) prior to introducing the System z10 server.</li>
<li>The Integrated Cluster Bus (ICB) connector on the System z10 server is different than on previous
servers, requiring new links and connectors to be installed on previous
servers in order to connect them to a System z10 server by ICB. This is a hardware-only migration
action.</li>
<li>The z10 EC model E64 servers
cannot use ICB-4 coupling links. On this model, all required coupling
link connectivity must be provided using PSIFB and/or ISC-3 coupling
links.</li></ul></li></ol>
<h3 id="wq121">Actions you can take before you order a System z10 server</h3>
<p>You can perform the following migration actions before you order
or install your System z10 server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in which the
System z10 server will participate.</strong> In
particular, if you have any existing z900 or z800 z/OS images or coupling facilities in the sysplex,
move these z/OS images or coupling
facilities to later servers (such as z990 or z890 or later). This
action is necessitated by the restriction that a System z10 server cannot participate with
a z900 or z800 in a sysplex.</li>
<li><strong>Install new links and connectors on earlier servers.</strong> This
action is necessitated because the ICB connector on the System z10 server is different than on previous
servers.</li>
<li><strong>Review restrictions and coexistence requirements
for earlier servers.</strong> Because the z9 EC
and z9 BC support is the basis
for the System z10 server support,
the restrictions and coexistence requirements for the z9 EC and z9 BC
also apply to the System z10 server.
For instance, large page support is not supported by z/OS when z/OS runs
as a guest under z/VM on a
System z10 server.  Review the
restrictions and coexistence requirements that were introduced for
the z9 EC, if you have not already
done so, and take any necessary actions. You can find the z9 EC restrictions and coexistence
requirements in <a href="#mtodanu">Migrate to a System z9 server</a>.<a id="idx183"></a><a id="idx184"></a><a id="idx185"></a></li>
<li><strong>Install the necessary z/OS service, as indicated in PSP buckets.</strong> The
appropriate PSP buckets are listed in <a href="#z10rmss">Recommended migration steps for a System z10 server</a> and are
dependent on the z/OS release
you will run on the System z10 server
and on the hardware support you already have installed. If you reviewed
the PSP buckets a long time ago, there might have been additions since
then, so ensure that any newly identified z/OS service has been installed. To assist you in
determining whether you have the recommended service installed on
your system, which is identified in these PSP buckets, you can use
the SMP/E REPORT MISSINGFIX command with a FIXCAT value of &quot;IBM.Device.Server.z10-EC-2097&quot; or &quot;IBM.Device.Server.z10-BC-2098&quot;,
the Enhanced PSP Tool (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
or ServiceLink's PSP Service Extraction tool. <a id="idx186"></a><a id="idx187"></a><a id="idx188"></a>
<p>If you use REPORT MISSINGFIX, some FIXCAT values you
can use for specific System z10 functions
are: </p>
<ul>
<li>IBM.Device.Server.z10-BC-2098.CapacityProvisioning</li>
<li>IBM.Device.Server.z10-BC-2098.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z10-BC-2098.MIDAW</li>
<li>IBM.Device.Server.z10-BC-2098.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z10-BC-2098.ServerTimeProtocol</li>
<li>IBM.Device.Server.z10-BC-2098.zAAP</li>
<li>IBM.Device.Server.z10-BC-2098.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z10-BC-2098.zIIP</li>
<li>IBM.Device.Server.z10-EC-2097.CapacityProvisioning</li>
<li>IBM.Device.Server.z10-EC-2097.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z10-EC-2097.MIDAW</li>
<li>IBM.Device.Server.z10-EC-2097.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z10-EC-2097.ServerTimeProtocol</li>
<li>IBM.Device.Server.z10-EC-2097.zAAP</li>
<li>IBM.Device.Server.z10-EC-2097.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z10-EC-2097.zIIP</li></ul></li>
<li><strong>Run CFSizer.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on later CFCC
levels than they were previously, run the Coupling Facility Structure
Sizer (CFSizer) tool to find out if you have to increase coupling
facility structure sizes. Prepare to make the necessary changes as
indicated by the tool. You can find the CFSizer tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.</li>
<li><strong>Plan for the System z10 fixed
HSA enhancement.</strong> With System z10 servers,
planning requirements are minimized by the availability of a fixed
HSA and introduction of the ability to seamlessly include events such
as creation of LPARs, inclusion of logical subsystems, changing logical
processor definitions in an LPAR, and introduction of cryptography
into an LPAR. For more information about this enhancement, see the
System z10 Redbooks.</li>
<li><strong>Decide on the steps you will take for your migration
to a System z10 server.</strong> 
As a guide, see <a href="#z10rmss">Recommended migration steps for a System z10 server</a>. Be aware of the following:
<ul>
<li>You should review the cryptographic support you currently have
installed versus the support required for the functions you plan to
use on the System z10 server.
Several cryptographic support web deliverables have been made available
for various z/OS releases.
The web deliverables listed in <a href="#z10rmss">Recommended migration steps for a System z10 server</a> are the minimum
web deliverable level for the function specified. When a subsequent
cryptographic web deliverable is available for a particular z/OS level, the previous one is
withdrawn. The newer cryptographic web deliverable, however, includes
the previous function (when applicable) for that particular z/OS level. Note that you can use
the newer cryptographic web deliverables on servers prior to the System z10 server (that is, on System z9 and zSeries servers).
<p>The level of cryptographic support
integrated in z/OS is ICSF
FMID HCR7751 in z/OS V1R11,
ICSF FMID HCR7770 in z/OS V1R12.
and ICSF FMID HCR7780 in z/OS V1R13.</p>
<p>Where
ICSF FMID HCR7751 is installed, the following coexistence support
is needed on other systems:</p>
<ul>
<li>PTF UA51214 (APAR OA29839) and PTF UA44731 (APAR OA26579) for
FMID HCR7750</li>
<li>PTF UA51212 (APAR OA29839), PTF UA37971 (APAR OA21807), and PTF
UA44730 (APAR OA26579) for FMID HCR7740</li></ul>
<p>Where ICSF FMID HCR7770 is installed, the following coexistence
support is needed on other systems:</p>
<ul>
<li>PTF UA51255 (APAR OA29997) and PTF UA51213 (APAR OA29839) for
FMID HCR7751</li>
<li>PTF UA51254 (APAR OA29997), PTF UA51214 (APAR OA29839), and PTF
UA44731 (APAR OA26579) for FMID HCR7750</li>
<li>PTF UA51253 (APAR OA29997), PTF UA51212 (APAR OA29839), PTF UA37971
(APAR OA21807), and PTF UA44730 (APAR OA26579) for FMID HCR7740</li></ul></li>
<li>You can migrate to z/OS V1R13
before or after you migrate to a System z10 server.</li></ul></li>
<li><strong>Upgrade your SCRT level if you want to process
System z10 SMF data.</strong> SCRT
V14.2.9 (Version 14 Release 2 Modification Level 9) provides support
for the System z10 server.  If
you collect SMF data on a System z10 server
and the data will be processed by the SCRT, you must minimally use
SCRT V14.2.9 to generate your SCRT reports.  If you do not need to
process SMF data from a System z10 server,
you are not required to download or use SCRT V14.2.9; you may continue
to use SCRT V14.1.0 or V14.2.0 until the next version upgrade of the
SCRT. SCRT V14.2.9 (or later) is available from the SCRT web site
at <a href="http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li>
<li><strong>Review the new mnemonics introduced for the System z10.</strong> In support of the System z10 server, HLASM introduced new
mnemonics for the new machine instructions. The new mnemonics might
collide with (be identical to) the names of assembler macro instructions
you use or provide. In the event of such collisions, the HLASM default
opcode table (UNI) will treat specification of these names as instructions
when the PTF for APAR PK58463 is installed.  This will probably cause
assembler error messages and possibly cause generation of incorrect
object code.
<p>If you write programs in assembler language, you should
compare the list provided in <cite>z/Architecture Principles of Operation</cite>, SA22-7832, to the names of
assembler macro instructions you use or provide, to identify any such
conflicts or collisions that would occur following installation of
the PTF for HLASM APAR PK58463.</p>
<p>To see the differences of supported
mnemonics before and after applying the PTF for APAR PK58463, assemble
an END statement with the PARM='OPTABLE(UNI,LIST)' option, and compare
the SYSPRINT files for the two assemblies.</p>
<p>If a conflict is
identified, take one of the following actions: </p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify <samp class="xph">PARM='...OPTABLE(YOP)...'</samp> or
some other, earlier opcode table.</li>
<li>Specify a separate ASMAOPT file containing assembler options as
in the previous method. This method requires no changes to source
code or JCL.</li>
<li>Add <samp class="xph">*PROCESS OPTABLE(YOP)</samp> as the first statement of
your source program.</li>
<li>Specify the PROFILE option in either JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the beginning of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique, where <em>XXX</em> is a sample mnemonic. (Assume that the default
OPTABLE(UNI) is in effect.)
<pre class="xmp"><code><em>XXX</em>   a,b       new instruction
PUSH  ACONTROL  save current optable definition
ACONTROL OPTABLE(YOP)   switch optable dynamically
<em>XXX</em>   r,s,t     macro invocation
POP   ACONTROL  restore previous definition
<em>XXX</em>   c,d       new instruction</code></pre></li></ul><p class="indatacontent">For more information about the HLASM opcode table, see >HLASM Programmer&rsquo;s Guide</a>.</p></li></ol>
<h3 id="wq123">Actions you can take after you order a System z10 server</h3>
<p>After you order but before you install your System z10 server, do the following:</p>
<ol type="1">
<li><strong>Use the CHPID Mapping Tool.</strong> As you might
have done with your z9 EC or z9 BC, use the CHPID Mapping Tool
to map logical CHPIDs to physical channels (PCHIDs) and create input
to HCD/IOCP for your System z10 server.
The tool is a workstation-based Java application
available from the Resource
Link web site (<a href="http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).
For more information about this tool, refer to the web site.</li>
<li><strong>Plan for the changes in hardware memory granularity
on a System z10 server.</strong> The
minimum hardware memory granularity for LPAR assignment to central
storage elements (initial and reserved) and for z/OS memory reconfiguration is changed on System z10 servers. On a z9 EC, z9 BC,
z990, and z890 it is 64 MB, on a z10 EC
it is 256 MB, and on a z10 BC
it is 128 MB. Addressability is also increased to 8 TB on a z10 EC. For more information, see >PR/SM Planning Guide</a>. 
<p>If
your installation is set up to do central memory reconfiguration with z/OS, you might have to change
your RSU setting in parmlib member IEASYS<var class="pv">xx</var>. You can specify
RSU as a number, a percentage of all storage, or in MB (or GB or TB). >z/OS MVS Initialization and Tuning Reference</a> states
that while number values from 1-9999 are supported, it is recommended
that you use the megabyte, gigabyte, or terabyte format. If you currently
specify RSU as a number, such as <samp class="xph">RSU=10</samp> on a System z9 server, this would result in 640
MB assuming a partition with the largest element of 32 GB or less
of central storage. However, on a z10 EC
with the same amount of central storage, the result would be 2560
MB. If you specify an RSU in MB or GB, there will probably be less
of an impact but you need to understand that the values are rounded
to a multiple of 256 MB instead of 64 MB or 128 MB.</p>
<p>Note that
specifying an RSU value greater than the total amount of real storage
available on the system will cause message IAR026I THE RSU VALUE SPECIFIED
EXCEEDS THE TOTAL AMOUNT OF REAL STORAGE AVAILABLE ON THIS SYSTEM: <span class="mv">yyyyyyyy</span>M
to be issued by the system during IPL indicating an RSU overspecification
condition, and showing the amount of real storage available on the
system. This message will be followed by IAR006A INVALID {VRREGN|REAL|RSU}
PARM - RESPECIFY OR PRESS ENTER FOR THE DEFAULT prompting for a valid
RSU value. Special care should be given to select the right RSU value
for the system. A large RSU value can ultimately cause system performance
problems.</p>
<div>
<div class="notetitle" id="wq125">Note:</div>
<div class="notebody"> Message IAR026I was introduced in z/OS V1R11, and rolled back to
prior releases, by RSM APAR OA27801. It is now integrated into the
base of z/OS V1R12.</div></div></li></ol>
<h3 id="z10rmss">Recommended migration steps for a System z10 server</h3>
<p>This topic suggests the steps for migrating your same z/OS release level from your current
server to a System z10 server.
The steps are based on the assumption that you want to minimize the
amount of change (and therefore risk) and the amount of work required
to perform the migration.</p>
<p><strong>If your current z/OS release
is V1R11, follow these steps:</strong> </p>
<ol type="1">
<li>Install the service in the following PSP buckets: 
<ul>
<li>The z10 PSP bucket: 
<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li>
<li>Upgrade your hardware to a System z10 server.
If you are migrating from a z990 or z890 server, see <a href="#mtodanu">Migrate to a System z9 server</a> for z9 EC and z9 BC migration considerations that
you must also satisfy.</li></ol>
<p><strong>If your current z/OS release
is V1R12, follow these steps:</strong> </p>
<ol type="1">
<li>Install the service in the following PSP buckets: 
<ul>
<li>The z10 PSP bucket: 
<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li></ol>
<p><strong>If your current z/OS release
is V1R13, follow these steps:</strong> </p>
<ol type="1">
<li>Install the service in the following PSP buckets: 
<ul>
<li>The z10 PSP bucket: 
<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li></ol>
<p><strong>Tip for locating the correct service:</strong> To
simplify finding the appropriate PSP bucket and identifying which
PTFs listed in the PSP bucket need to be installed on your system,
use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT
type of HOLDDATA, as follows:</p>
<ol type="1">
<li>Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V1R13
systems. Use your normal service acquisition portals or download the
HOLDDATA directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you use the FULL file (last 730 days) to receive the FIXCAT
HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V1R13
systems and specify a Fix Category (FIXCAT) value of &quot;IBM.Device.Server.z10-BC-2098&quot; or &quot;IBM.Device.Server.z10-EC-2097&quot;.
The report will identify any missing coexistence and fallback PTFs
for that system. For complete information about the REPORT MISSINGFIX
command, see >SMP/E Commands</a>.</li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
coexistence and fallback PTFs.</li></ol>
<h3 id="wq130">Migration and exploitation considerations for System z10 functions</h3>
<p></p>
<ol type="1">
<li><strong>C/C++ ARCH(8) and TUNE(8) options:</strong> <a id="idx189"></a><a id="idx190"></a>The ARCHITECTURE option of the XL C/C++
compiler selects the minimum level of machine architecture on which
your programs will run. Certain features provided by the compiler
require a minimum architecture level. ARCH(8) exploits instructions
available on System z10 servers.
For more information, refer to the ARCHITECTURE compiler option in >z/OS XL C/C++ User&rsquo;s Guide</a>.
The TUNE compiler option allows you to optimize your application for
a specific machine architecture within the constraints imposed by
the ARCHITECTURE option. The TUNE level must not be lower than the
setting in the ARCHITECTURE option. For more information, refer to
the TUNE compiler option in >z/OS XL C/C++ User&rsquo;s Guide</a>.
You must have at least the z/OS V1R9
XL C/C++ compiler to use this function.
<p><strong>Exploitation
restriction:</strong> Once programs exploit the ARCH(8) or TUNE(8) option,
the programs can only run on System z10 servers;
otherwise, an operation exception will occur. This is a consideration
for programs that will run on different server levels (System z9 and zSeries) during development, test, and production,
as well as during fallback or disaster recovery.</p>
<div>
<div class="notetitle" id="wq132">Note:</div>
<div class="notebody">ARCH(7)
is the minimum level required to exploit decimal floating point support.
The resulting program objects can run on System z9 servers (depending on the MLC installed) as well
as on System z10 servers.</div></div></li>
<li><strong>HiperDispatch:</strong> <a id="idx191"></a>A new HIPERDISPATCH=YES|NO parameter in parmlib member IEAOPT<var class="pv">xx</var>,
and on the SET OPT=<var class="pv">xx</var> command, controls whether HiperDispatch
is enabled or disabled for the system. The value can be changed dynamically.
 HiperDispatch defaults to disabled. Thus, by default, your environment
is not changed from a HiperDispatch perspective when migrating from
a pre-System z10 server to a
System z10 server.  Once migration
has completed, you can exploit the HiperDispatch function of the System z10 server.
<p>Because HiperDispatch
improves the performance of a System z10 system,
a new health check (SUP_HIPERDISPATCH) was added to verify that HiperDispatch
is enabled. The new health check is only added on System z10 systems. WLM goal adjustment
might be required when using this function. Review and update your
WLM policies as necessary. You might need to turn off and on HiperDispatch
while adjusting your WLM goals.</p></li>
<li><strong>Capacity Provisioning:</strong>  <a id="idx192"></a>An installed On/Off CoD record is a necessary
prerequisite for automated control of temporary capacity through z/OS Capacity Provisioning. Capacity
Provisioning allows you to set up rules defining the circumstances
under which additional capacity should be provisioned in order to
fulfill a specific business need. The rules are based on criteria,
such as the maximum additional capacity that may be activated for
one or more workloads, and time and workload conditions. The workload
condition can identify a specific application by use of WLM service
classes. Capacity changes can be suggested or implemented automatically,
when authorized by policy. This support provides a fast response to
capacity changes and ensures sufficient processing power will be available
with the least possible delay even if workloads fluctuate. For more
information, see >z/OS MVS Capacity Provisioning User&rsquo;s Guide</a>.</li>
<li><strong>Large page support:</strong>  <a id="idx193"></a>A change to the z/Architecture on System z10 servers is designed to allow memory to be extended
to support large (1 MB) pages. Large pages are used in addition to
the existing 4 KB pages. The use of large pages is expected to reduce
memory management overhead for exploiting applications.
<p>Large page
support is primarily of benefit for long-running applications
that are memory-access intensive. Large page support is not recommended
for general use. Short-lived processes with small working sets
are normally not good candidates for large pages.</p>
<p>To
use large pages, you need to run z/OS V1R9
(or later) with the appropriate PTFs in a native System z10 LPAR. The support is not enabled
if you are running without the software support, are running on a
prior generation of server, or are running as a z/OS guest under z/VM.
Without the large page support, page frames are allocated at the (current)
4 KB size.</p>
<p>Furthermore, to exploit large page frames, a new
LFAREA=xx%|xxxxxxM|xxxxxxG parameter in parmlib member IEASYS<var class="pv">xx</var> must
be specified. This parameter cannot be changed dynamically.</p>
<p>With
the installation of APAR OA32001, the calculation of the max value
of the LFAREA is changed. The LFAREA max value is now less than the
old max LFAREA value. The maximum amount of real storage that can
be used to back large pages is now (80% of the online storage available
at IPL) minus 2 GB. Make sure the LFAREA value you specify in the
IEASYS<var class="pv">xx</var> member is less than the new max value available
in the system. You can specify LFAREA as a percentage of all storage,
or in MB or GB. Specifying a percentage for the LFAREA parameter is
now also calculated as (the percent of the online storage available
at IPL) minus 2 GB. Special care should be given to select the right
LFAREA value for the system. See >z/OS MVS Initialization and Tuning Reference</a> and
DOC APAR OA34024 for information about valid specification of the
LFAREA parameter.</p>
<p></p>
<div>
<div class="notelisttitle" id="wq133">Notes:</div>
<ol type="a">
<li>You must apply the PTF for APAR OA31116 to z/OS V1R11 and z/OS V1R12 to use the command <span class="pk">DISPLAY VIRTSTOR,LFAREA</span> to
find the allocation status of LFAREA.</li>
<li>If you do not want large frame support, do not use LFAREA= to
exploit large page frames. If LFAREA=0M is explicitly specified on
a system where large page support is not desired, message IAR021I
THE LFAREA WAS SPECIFIED BUT SUFFICIENT STORAGE IS NOT AVAILABLE is
issued. The system correctly does not provide any large frames in
this case.</li>
</ol></div></li>
<li><strong>Coupling facility level 16:</strong> Service time
for CF duplexing is improved, shared IMS and
MQ list notification is improved, and the structure increment size
is increased from 512 KB to 1 MB.</li>
<li><strong>Parallel
Sysplex InfiniBand (PSIFB) coupling links:</strong> <a id="idx194"></a><a id="idx195"></a><a id="idx196"></a>InfiniBand
coupling links provide an additional option for your Parallel Sysplex cluster
on System z10 and System z9. When used in the data center,
InfiniBand coupling links can replace Integrated Cluster Bus-4
(ICB-4) and InterSystem Channel-3 (ISC-3) links.
<div>
<div class="notetitle" id="wq135">Note:</div>
<div class="notebody"> Be
sure to conduct performance analyses when replacing one type of coupling
link with another.</div></div>
<p>Coupling facilities can now
be separated by up to 150 meters (492 feet).</p>
<p>InfiniBand coupling
links use fiber optic cabling containing 12 pairs (12x) of fiber compared
to one pair (1x) of fiber used with ISC-3 fiber optic cabling. InfiniBand
coupling links support double data rate (DDR) when a z10 EC is communicating with another z10 EC. InfiniBand coupling links support single
data rate (SDR) when a z10 EC
is communicating with a z9 EC
dedicated CF or z9 BC Model S07
dedicated CF. When the InfiniBand coupling link is z10 EC-to-z10 EC, the link auto-negotiates to 6 GBps.
A z10 EC system auto-negotiates
to 3 Gbps when connected to a z9 EC
or z9 BC dedicated coupling facility.</p>
<div>
<div class="notetitle" id="wq136">Note:</div>
<div class="notebody">The InfiniBand link data rate of 6 Gbps or 3 Gbps does not
represent the performance of the link. The actual performance is dependent
upon many factors including latency through the adapters, cable lengths,
and the type of workload. With InfiniBand coupling links, while the
link data rate may be higher than that of ICB, the service times of
coupling operations are greater, and the actual throughput may be
less than with ICB links.</div></div>
<p>Refer to the <em>Coupling Facility Configuration Options</em> white
paper for a more specific explanation of when to continue using the
current ICB technology versus migrating to InfiniBand coupling links.
The white paper is available at <a href="http://www.ibm.com/systems/z/advantages/pso/whitepaper.html">http://www.ibm.com/systems/z/advantages/pso/whitepaper.html</a>.</p>
<p>A
new infrastructure was created to support an InfiniBand coupling link
environment. Host channel adapter optical (HCA-O) fanouts have been
introduced for System z10 and
System z9 dedicated coupling
facilities. The HCA-O fanouts, with two ports per fanout, reside on
the front of each processor book. The fiber optic cables are plugged
directly into the front of the HCA-O fanouts:</p>
<ul>
<li>HCA2-O fanout for System z10 servers</li>
<li>HCA1-O fanout for z9 EC and z9 BC Model S07 dedicated coupling
facilities</li></ul>
<p>There is a new physical definition to associate with a
channel path identifier with an adapter identification. Unlike channels
installed in an I/O cage, which are identified by a physical channel
path identifier (PCHID) number related to their physical location,
HCA-O fanouts and ports are identified by an adapter identification
(AID) value that is determined by its physical location. The AID must
be used to assign a CHPID to the fanout in the hardware configuration
definition. The CHPID assignment is done by associating the CHPID
to an AID and port. The AID assigned to a fanout can be found in the
PCHID report provided for each new server or for upgrades on System z10 and System z9 servers.</p>
<p>There is also a new CHPID type
CIB (coupling using InfiniBand). CHPID type CIB is common for System z10 and System z9 servers.</p>
<p>On System z10 and System z9 servers,
the design allows up to 16 CHPIDs to be defined across the two ports
on each HCA-O fanout. This can reduce the number of coupling links;
physical coupling links can be shared by multiple sysplexes. For example,
this capability allows for one CHPID to be directed to one coupling
facility and a second CHPID to be directed to a separate coupling
facility on the same target server, using the same port. An increased
number of CHPIDs per physical link can help to facilitate consolidation
of ISC-3 links onto InfiniBand coupling links.</p>
<p>InfiniBand coupling
links can also be used to exchange timekeeping messages for Server
Time Protocol (STP).</p>
<p>You can choose the coupling links that
best suit your business needs: IC, ICB, IFB, or ISC-3.</p></li></ol>
<h2 id="mtodanu">Migrate to a System z9 server</h2>
<p><strong>Description:</strong> The IBM System z9 servers
(z9 EC [formerly z9-109] and z9 BC)
are follow-ons to the IBM eServer zSeries servers (z990, z890, z900, and z800). They
continue the evolution of the mainframe, building on the structure
introduced with the z990 in support of z/Architecture, reliability, availability, scalability,
and clustering. System z9 servers
expand upon a key attribute of the platform, availability, to help
ensure that you have a resilient infrastructure designed to satisfy
the requirements of on demand business. With the increased performance
and total system capacity possible for System z9 servers, you have an opportunity to continue
to consolidate diverse applications on a single platform.</p><a id="idx197"></a><a id="idx198"></a><a id="idx199"></a><a id="idx200"></a><a id="idx201"></a><a id="idx202"></a><a id="idx203"></a><a id="idx204"></a>
<p>The specific System z9 functions
exploited by z/OS V1R13, V1R12,
and V1R11 are:</p>
<ol type="1">
<li>Separate LPAR management of processor units (PUs)</li>
<li>63.75K subchannel support</li>
<li>OSA-Express2 Gigabit Ethernet (LX and SX)</li>
<li>OSA-Express2 1000BASE-T Ethernet</li>
<li>OSA-Express2 10 Gigabit Ethernet (LR)</li>
<li>OSA/SF IP and MAC addressing</li>
<li>FICON Express4 (4KM LX,
10KM LX, and SX)</li>
<li>CP Assist for Cryptographic Functions (CPACF) clear key</li>
<li>Crypto Express2 as a coprocessor (secure key)</li>
<li>Request node identification data (RNID) for native FICON</li>
<li>Channel Data Link Control (CDLC) support</li>
<li>Up to 60 LPARs on z9 EC and
30 LPARs on z9 BC</li>
<li>Crypto Express2 as an accelerator</li>
<li>CPACF enhancements (AES, SHA-256, and PRNG)</li>
<li>Remote Keyload for ATMs and POSs, and ISO 16609 CBC Mode TDES
for MAC</li>
<li>Modified Indirect Data Address Word (MIDAW) support</li>
<li>zIIP support</li>
<li>Multiple subchannel sets</li>
<li>HiperSockets support
of IPv6</li>
<li>Virtual local area network (VLAN) management enhancements</li>
<li>FICON link incident reporting</li>
<li>XLC C/C++ (enable ARCH(7) and TUNE(7) compiler options)</li>
<li>Up to 512 GB real storage on z9 EC
(GB equals 1 073 741 824 bytes)</li></ol>
<table id="wq138" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The first System z9 server,
the z9 EC, shipped in September
2005.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS on a System z9 server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>A System z9 server.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>See the appropriate PSP buckets for required
PTFs for specific functions, as described in &quot;Steps to take&quot;.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the recommendations
and considerations, adhere to the restrictions, and perform the tasks
described in the topics below.</p>
<h3 id="wq139">General recommendations and considerations for a System z9 server</h3>
<p>As you plan your migration to a System z9 server,
consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when
coming from a z990 or z890.</strong> Migration to a System z9 server has, as its basis, a migration to a z990
or z890. This means that if you are migrating to a System z9 server from a z990 or z890 (and
have performed the migration actions associated with the z990 or z890),
you have fewer migration actions than if you were migrating from a
server prior to the z990 or z890 and have not yet performed the migration
actions associated with the z990 and z890. There are, in fact, very
few new migration actions to perform on z/OS for
a System z9 server if you have
already migrated to a z990 or z890. It is important to note that you
can migrate directly to a System z9 server
without installing the intermediate (prior to z990 and z890) servers,
but you still need to ensure that any migration considerations are
satisfied for the servers that you &quot;skipped&quot;. To read about
z990 and z890 migration actions, see <a href="#mtoz990">Migrate to a z990 or z890 server</a>.</li>
<li><strong>Support is delivered by service and FMIDs.</strong> The
delta (from a z990 or z890) support for a System z9 server, excluding cryptographic support, is delivered
by service (PTFs), unlike the support that was required for the z990
and z890. The z990 and z890 support was delivered with service and
FMIDs (web deliverables and features).  The cryptographic support
for the System z9 servers continues
to be FMIDs, many of which are still available in web deliverables.
Different web deliverables, providing different levels of support,
are available for different releases of z/OS.</li>
<li><strong>Larger coupling facility structure sizes might
be necessary.</strong> When you change coupling facility control code
(CFCC) levels, your coupling facility structure sizes might change.
System z9 servers initially ship
with CFCC Level 14. If, as part of your migration to a System z9 server, you change CFCC levels
(either by placing a coupling facility on the System z9 server or by moving the coupling facility to
a z990 or z890 at a later CFCC level), you might have larger structure
sizes than you did previously.  If your CFCC levels are identical,
structure sizes are not expected to change when you migrate from a
previous server to a System z9 server.</li>
<li><strong>Update CFRM policies.</strong> Coupling facilities
are identified in the CFRM policy by their physical node descriptor
information (for example, machine type, model, serial number, LPAR
number). When a coupling facility undergoes a hardware upgrade, one
or more of these pieces of information is likely to change, therefore,
the definition of the coupling facility in the CFRM policy must change
accordingly.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To
minimize the amount of change (and therefore risk) that you experience
at one time, do not migrate your software release level at the same
time that you migrate your hardware.</li></ol>
<h3 id="restric">Restrictions for a System z9 server</h3>
<p>Restrictions associated with the System z9 server are:</p>
<ol type="1">
<li><strong>z/OS as
a guest of z/VM:</strong> Modified
indirect data address words (MIDAWs) and subchannel sets are not supported
by z/OS when z/OS runs as a guest under z/VM on a System z9 server.</li>
<li><strong>System z9 server
in a sysplex:</strong> 
<ul>
<li>Integrated Cluster Bus-2 (ICB-2) and InterSystem Channel-3 (ISC-3)
compatibility mode links are not supported on System z9 servers. If you have ICB-2 or ISC-3 compatibility
mode links defined, convert them to a supported link technology.</li>
<li>If you have a G5 or G6 coupling facility image, you cannot connect
that coupling facility to any System z9 z/OS senders (or, for duplexing,
to a System z9 coupling facility).
Having a G5 or G6 coupling facility, therefore, introduces coexistence
issues if any System z9 z/OS images, or System z9 coupling facilities, participating
in that sysplex.</li></ul></li>
<li><strong>HMC:</strong> The hardware management console (HMC)
is for the exclusive use of the HMC application.  Customer applications
cannot reside on the HMC. The ESCON Directory
and Sysplex Timer applications
cannot reside on the HMC. TCP/IP is the only supported communication
protocol. The HMC supports System z9 servers.
 It can also be used to support z990, z890, z900, z800, G5, G6, and Multiprise 3000
servers. They must be upgraded to a new AROM level.</li>
<li><strong>Token Ring:</strong> 
<ul>
<li>Token Ring is not available as a feature on the System z9 HMC. Current&reg; HMCs with Token Ring may be carried forward
to a System z9 server during
an upgrade from a z990 or z900.</li>
<li>Token Ring is not available as a feature on the System z9 Support Element (SE) or Trusted
Key Entry (TKE) workstation. Token Ring is not offered as a feature
on System z9 servers and cannot
be carried forward to a System z9 server
during an upgrade from a z990 or z900.</li>
<li>The OSA-Express Token Ring feature is not supported on System z9 servers. Token Ring is not offered
as a feature on System z9 servers
and cannot be carried forward to a System z9 server
during an upgrade from a z990 or z900.</li></ul></li>
<li><strong>C/C++ ARCH(7) and TUNE(7) options:</strong> The ARCHITECTURE
C/C++ compiler option selects the minimum level of machine architecture
on which your program will run. Certain features provided by the compiler
require a minimum architecture level. ARCH(7) exploits instructions
available on System z9 servers.
For more information, refer to the ARCHITECTURE compiler option in >z/OS XL C/C++ User&rsquo;s Guide</a>.
<p>The
TUNE compiler option allows you to optimize your application for a
specific machine architecture within the constraints imposed by the
ARCHITECTURE option. The TUNE level must not be lower than the setting
in the ARCHITECTURE option. For more information, see the TUNE compiler
option in >z/OS XL C/C++ User&rsquo;s Guide</a>.</p>
<p><strong>Exploitation restriction:</strong> Once programs exploit
the ARCH(7) or TUNE(7) option, those programs can only run on System z9 servers, or an operation exception
will occur. This is a consideration for programs that will run on
different server levels (System z9 and zSeries) during development,
test, and production, as well as during fallback or disaster recovery.</p></li></ol>
<h3 id="miganow">Actions you can take before you order a System z9 server</h3>
<p>You can perform the following migration actions before you order
or install your System z9 server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in which the
System z9 server will participate.</strong> In
particular, if you have any existing G5 or G6 coupling facilities
in the sysplex, move those coupling facilities to later servers (such
as z990 or z890).  This action is necessitated by the restriction
that System z9 z/OS images in a sysplex cannot use G5 or G6 coupling
facilities, nor can G5 or G6 coupling facilities duplex with a System z9 coupling facility.</li>
<li><strong>Review your current link technology.</strong> If
you have any ICB-2 or ISC-3 compatibility mode links, convert them
to a supported link technology.</li>
<li><strong>Review coexistence requirements.</strong> Because
the z990 and z890 support is the basis for the System z9 server support, the coexistence requirements
for the z990 and z890 also apply to the System z9 server. For instance, ICKDSF R17 must be installed
on all z/OS and z/VM images that will share DASD
with the z990 or z890 (and therefore, with System z9 servers). Review the coexistence requirements
that were introduced for the z990, if you have not already done so,
and take any necessary actions. You can find the z990 coexistence
requirements in <a href="#mtoz990">Migrate to a z990 or z890 server</a>.<a id="idx205"></a><a id="idx206"></a><a id="idx207"></a></li>
<li><strong>Install the necessary z/OS service, as indicated in PSP buckets.</strong> The
appropriate PSP buckets are listed in <a href="#recscen">Recommended migration steps for a System z9 server</a> and are
dependent on the z/OS release
you will run on the System z9 server
and on the hardware support you already have installed. If you reviewed
the PSP buckets a long time ago, there might have been additions since
then, so ensure that any newly identified z/OS service has been installed. To assist you in
determining whether you have the recommended service installed on
your system, which is identified in these PSP buckets, you can use
the SMP/E REPORT MISSINGFIX command with a FIXCAT value of &quot;IBM.Device.Server.z9-EC-2094&quot; or &quot;IBM.Device.Server.z9-BC-2096&quot;,
the Enhanced PSP Tool (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
or ServiceLink's PSP Service Extraction tool.<a id="idx208"></a><a id="idx209"></a><a id="idx210"></a>
<p>If you use REPORT MISSINGFIX, some FIXCAT values you
can use for specific System z9 functions
are: </p>
<ul>
<li>IBM.Device.Server.z9-BC-2096.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z9-BC-2096.MIDAW</li>
<li>IBM.Device.Server.z9-BC-2096.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z9-BC-2096.ServerTimeProtocol</li>
<li>IBM.Device.Server.z9-BC-2096.zAAP</li>
<li>IBM.Device.Server.z9-BC-2096.zIIP</li>
<li>IBM.Device.Server.z9-EC-2094.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z9-EC-2094.MIDAW</li>
<li>IBM.Device.Server.z9-EC-2094.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z9-EC-2094.ServerTimeProtocol</li>
<li>IBM.Device.Server.z9-EC-2094.zAAP</li>
<li>IBM.Device.Server.z9-EC-2094.zIIP</li></ul></li>
<li><strong>Run CFSizer.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on later CFCC
levels than they were previously, run the Coupling Facility Structure
Sizer (CFSizer) tool to find out if you have to increase coupling
facility structure sizes. System z9 servers
initially ship with CFCC Level 14. Prepare to make the necessary changes
as indicated by the tool. You can find the CFSizer tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.</li>
<li><strong>Estimate the amount of HSA needed.</strong> If you
intend to add more devices, exploit subchannels, or use more LPARs
on the System z9 server than
you did on your previous server, you should estimate the amount of
hardware system area (HSA) that will be necessary on the System z9 server.  Use the HSA Estimator
tool, which is available on Resource
Link (<a href="http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).</li>
<li><strong>Decide on the steps you will take for your migration
to a System z9 server.</strong> 
As a guide, see <a href="#recscen">Recommended migration steps for a System z9 server</a>. Be aware of the following:
<ul>
<li>You should review the cryptographic support you currently have
installed versus the support required on the System z9 server. Several cryptographic support web deliverables
have been made available for various z/OS releases.
The web deliverables listed in <a href="#recscen">Recommended migration steps for a System z9 server</a> are the minimum
web deliverable level for the function specified. When a subsequent
cryptographic web deliverable is available for a particular z/OS level, the previous one is
withdrawn. The newer cryptographic web deliverable, however, includes
the previous function (when applicable) for that particular z/OS level. Note that you can use
the newer cryptographic web deliverables on servers prior to the System z9 server (that is, on zSeries servers).
<p>The level
of cryptographic support integrated in z/OS V1R11
is ICSF FMID HCR7751. ICSF FMID HCR7770 (integrated in z/OS V1R10) available as a web
deliverable for cryptographic support for z/OS V1R9, z/OS V1R10,
and z/OS V1R11.</p></li>
<li>You can migrate to z/OS V1R13
before or after you migrate to a System z9 server.</li></ul></li></ol>
<h3 id="wq143">Actions you can take after you order a System z9 server</h3>
<p>After you order but before you install your System z9 server, do the following:</p>
<ol type="1">
<li><strong>Use the CHPID Mapping Tool.</strong> As you might
have done with your z990 or z890, use the CHPID Mapping Tool to map
logical CHPIDs to physical channels (PCHIDs) and create input to HCD/IOCP
for your System z9 server. The
tool is a workstation-based Java application
available from the Resource
Link web site (<a href="http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).
For more information about this tool, refer to the web site.</li></ol>
<h3 id="recscen">Recommended migration steps for a System z9 server</h3>
<p>This topic suggests the steps for migrating your same z/OS release level from your current
server to a System z9 server.
The steps are based on the assumption that you want to minimize the
amount of change (and therefore risk) and the amount of work required
to perform the migration.</p>
<p>Your migration steps are:</p>
<ol type="1">
<li>Install the service in the following PSP buckets: 
<ul>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS</li>
<li>The z9 BC PSP bucket: upgrade
2096DEVICE, subset 2096/ZOS</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS</li></ul></li>
<li>Upgrade your hardware to a System z9 server.
If you are migrating from a z900 or z800 server, see <a href="#mtoz990">Migrate to a z990 or z890 server</a> for z990 and z890 migration considerations that you
must also satisfy.</li></ol>
<p><strong>Tip for locating the correct service:</strong> To
simplify finding the appropriate PSP bucket and identifying which
PTFs listed in the PSP bucket need to be installed on your system,
use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT
type of HOLDDATA as follows:</p>
<ol type="1">
<li>Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V1R13
systems. Use your normal service acquisition portals or download the
HOLDDATA directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you use the FULL file (last 730 days) to receive the FIXCAT
HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V1R13
systems and specify a Fix Category (FIXCAT) value of &quot;IBM.Device.Server.z9-BC-2096 &quot; or &quot;IBM.Device.Server.z9-EC-2094 &quot;.
The report will identify any missing coexistence and fallback PTFs
for that system. For complete information about the REPORT MISSINGFIX
command, see >SMP/E Commands</a>.</li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
coexistence and fallback PTFs.</li></ol>
<h3 id="futhard">Accommodate functions for the System z9 platform to be discontinued on future servers</h3>
<p><strong>Description:</strong> The following future
changes in hardware support could affect your environment:</p>
<ul>
<li><strong>Token ring:</strong> The z990 and z890 are the last
servers to offer token ring adapter features on the hardware management
consoles (HMCs), Support Elements (SEs), and Trusted Key Entry (TKE)
workstations. Thus:
<ul>
<li>Token ring is not available as a feature on the System z10 or System z9 HMC. Current HMCs
with token ring may be carried forward to a System z10 or System z9 server during an upgrade from a z990 or z900.</li>
<li>Token ring is not available as a feature on the System z10 or System z9 SE or TKE workstation. Token ring is not offered
as a feature on System z10 and System z9 servers and cannot be carried
forward to a System z10 or System z9 server during an upgrade from
a z990 or z900.</li>
<li>The OSA-Express Token Ring feature is not supported on System z10 and System z9 servers. Token ring is not offered as a feature
on System z10 and System z9 servers and cannot be carried
forward to a System z10 or System z9 server during an upgrade from
a z990 or z900.</li></ul></li>
<li><strong>HMC:</strong> The z990 and z890 are the last servers
on which the HMC is open. Starting with System z9 servers, the HMC is for the exclusive use of
the HMC application. Customer applications cannot reside on the HMC.
The ESCON Directory and Sysplex Timer applications
cannot reside on the HMC. TCP/IP is the only supported communication
protocol. The HMC supports System z10 and System z9 servers. It can also be used to
support z990, z890, z900, z800, G5, G6, and Multiprise 3000 servers. They
must be upgraded to a new AROM level.</li>
<li><strong>ICB-2s and ISC-3s in compatibility mode:</strong> The
z990 and z890 are the last servers to support Integrated Cluster Bus-2
(ICB-2) and InterSystem Channel-3 (ISC-3) compatibility mode links. System z10 and System z9 servers do not support them. If you have ICB-2
or ISC-3 compatibility mode links defined, convert them to a supported
link technology.</li></ul>
<table id="wq147" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>27 July 2005 in the z9 EC
(formerly z9-109) announcement.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before migrating to a System z10 or System z9 server.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you plan to install a System z10 or System z9 server and are affected by any support changes
mentioned in &quot;Description&quot; above.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>See &quot;Description&quot; above.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Take into account the statements
in &quot;Description&quot; above as you make your plans for the future.</p>
<p><strong>Reference information:</strong> None.</p>
<h2 id="mtoz990">Migrate to a z990 or z890 server</h2>
<p><strong>Description:</strong> The IBM eServer zSeries 990 (z990) and zSeries 890 (z890) represent
the second generation of zSeries servers.
The z990 and z890 servers provide more processing power, memory, and
I/O capacity than the first generation of zSeries servers (z900 and z800). By migrating to z/OS V1R13 on a z990 or z890 server,
you can take advantage of these improvements.</p><a id="idx211"></a><a id="idx212"></a><a id="idx213"></a><a id="idx214"></a><a id="idx215"></a><a id="idx216"></a><a id="idx217"></a><a id="idx218"></a><a id="idx219"></a><a id="idx220"></a><a id="idx221"></a><a id="idx222"></a><a id="idx223"></a><a id="idx224"></a><a id="idx225"></a><a id="idx226"></a><a id="idx227"></a><a id="idx228"></a>
<table id="wq148" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td width="25%"><strong>Element or feature:</strong></td>
<td width="75%">Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The first z990 server shipped in June 2003.
The first z890 server shipped in May 2004.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS on a z990 or z890 server. Also, be aware that
if any non-z990, non-z890 systems coexist with z990 or z890 systems,
coexistence requirements affect the non-z990, non-z890 systems.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>A z990 or z890 server and, for cryptography,
the following hardware features: PCI X Cryptographic Coprocessor (PCIXCC),
CP Assist for Cryptographic Functions (CPACF) DES/TDES, and PCI Cryptographic
Accelerator (PCICA).</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>For shared DASD requirements, see item <a href="#iz9scso">4</a>. For CFCC coexistence requirements, see item <a href="#izcfccc">6</a>.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>
<ul>
<li>Only LPAR mode (not basic mode) is supported on a z990 or z890
server.</li>
<li>Also, see the note <a href="#pcffnsu">***</a>.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>A power-on reset is required when adding or
removing a Logical Channel Subsystem (LCSS), changing the maximum
number of devices for an LCSS, adding or deleting LPARs, and adding
or changing a resource in an LCSS other than LCSS 0.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the requirements and
recommendations below. Included is information about required HMC
levels, configuring a z990 or z890 server, installing software and
microcode for coexistence with a z990 or z890 server, cryptographic
considerations, and operational considerations.</p>
<p>First, some general considerations and reminders:</p>
<ul>
<li>z/OS V1R5 and later contains
z990 exploitation support.</li>
<li>Minimizing the number of changes you make concurrently makes it
easier to pinpoint problems. Therefore, avoid upgrading your software
release level at the same time that you upgrade your hardware.</li>
<li>Having members of the sysplex at the same software level, except
for brief migration periods, is good software management policy.</li></ul>
<h3 id="wq149">Actions you can take before you install a z990 or z890 server</h3>
<ol type="1">
<li><strong>Upgrade HMC microcode.</strong> Upgrade the hardware
management console (HMC) driver level to 1.8.0 or later. IBM recommends migrating z900 and
z800 HMCs to HMC driver level 1.8.0 or later before z990 or z890 installation.<a id="idx229"></a></li>
<li><strong>Review PSP buckets.</strong> You should review and
install all the applicable service in the 2084DEVICE (for z990) or
2086DEVICE (for z890) PSP bucket. To assist you in determining whether
you have the recommended service installed on your system, which is
identified in these PSP buckets, you can use the SMP/E REPORT MISSINGFIX
command with a FIXCAT value of &quot;IBM.Device.Server.z990-2084 &quot; or &quot;IBM.Device.Server.z890-2086&quot;,
the Enhanced PSP Tool (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
or ServiceLink's PSP Service Extraction tool.<a id="idx230"></a><a id="idx231"></a><a id="idx232"></a>
<p>If you use REPORT MISSINGFIX, some FIXCAT values you
can use for specific server functions are: </p>
<ul>
<li>IBM.Device.Server.z990-2084.ServerTimeProtocol</li>
<li>IBM.Device.Server.z990-2084.zAAP</li>
<li>IBM.Device.Server.z890-2086.ServerTimeProtocol</li>
<li>IBM.Device.Server.z890-2086.zAAP</li></ul></li>
<li><strong>Define the z990 or z890 server.</strong> Use HCD
to define the z990 or z890 server.
<p>When installing a new (&quot;net
add&quot;) z990 or z890 server, you must define the operating system
and processor. You can use the copy or migrate functions of HCD to
model these definitions after an existing processor.</p>
<p>When using
a miscellaneous equipment specification (MES) package to upgrade a
z900 server to a z990 server, or to upgrade a z800 server to a z890
server, or when replacing one or more z900 servers (or z800 servers)
with a z990 or z890 server (a &quot;box swap&quot; or &quot;push/pull&quot;),
you must copy or migrate the existing definitions to a z990 or z890
Logical Channel Subsystem (LCSS).  IBM recommends
the following:</p>
<ul>
<li>Ensure that the production input/output definition file (IODF)
that will be used to migrate existing definitions contains <em>all</em> the definitions for <em>all</em> the
items to be migrated (operating system configurations, ESCON and FICON switches, logical partitions, channels, control
units, devices, and coupling facility processors).  Using one source
IODF means that there will be no conflict to be resolved during the
migration process with any control unit or device for address or number
definition conflict, address or number range conflict, or type definition
conflict.</li>
<li>If you are consolidating two processors into a z990 or z890 server,
copy or migrate one processor into LCSS 0 and the other into LCSS
1.</li></ul>
<p>When making the z990 or z890 hardware definitions, you
must:</p>
<ul>
<li><em>Define the z990 or z890 processor.</em> Only
LPAR mode is allowed.  You also need to define the number of LCSSs
that you intend to use. Note that increasing or decreasing the number
of LCSSs will require a power-on reset of a new input/output configuration
data set (IOCDS). IBM recommends
that when you define a z990 or z890 server, you should initially define
the number of LCSSs you expect to use -- up to two LCSSs on a
z890 or up to four LCSSs on a z990.</li>
<li><em>Define the channel subsystems.</em> For each
channel subsystem, specify an LCSS ID, a description, and the maximum
number of devices:
<div>
<div class="notelisttitle" id="wq151">Notes:</div>
<ol type="a">
<li>There is no hardware system area (HSA) expansion support on the
z990 or z890 support element (SE). The maximum number of devices,
defined for each LCSS, replaces the HSA expansion percentages in the
central processor complex (CPC) activation profile on the support
element.</li>
<li>If you change the maximum number of devices in an LCSS, you cannot
do an ACTIVATE; you must do a power-on reset. IBM recommends that when you define a z990 or z890
server, you initially define the maximum number of devices that you
expect to use in the future.</li>
<li>Because of the increase in the number of LPARs and LCSSs, be sure
that the value specified on the MAXDEV keyword is large enough. (Increasing
MAXDEV requires a power-on reset).  The HCD default for maximum number
of devices is 63K.  This could result in a large amount of HSA storage
being wasted.</li>
</ol></div></li>
<li><em>Define logical partitions.</em> The partition
names may not be duplicated across LCSSs. On servers other than z990
and z890 servers, partition numbers are the same as Multiple Image
Facility (MIF) IDs. On z990 and z890 servers, partition numbers are
assigned at power-on reset based on the IOCDS.  MIF IDs are still
specified using HCD/IOCP. On z990 and z890 servers, the partition
number can be in the range 1-30 (<span class="hex">X'1-1E'</span>) and
the MIF ID must be in the range 1-15 (<span class="hex">X'1-F'</span>). The
partition number will be unique across all LCSSs. The MIF ID must
be unique within each LCSS, but can be duplicated across LCSSs. Note
that partition numbers are not related to LPAR IDs, which are specified
in the HMC image profile.
<div>
<div class="notelisttitle" id="wq153">Notes:</div>
<ol type="a">
<li>IBM recommends when you
define a z990 or z890 server, you should initially define the number
of logical partitions that you expect to use.
<p>If you plan to exploit
more than 15 LPARs, then define the number of LCSSs (two or more)
that you expect to use. For exploiting more than 15 LPARs and more
than one LCSS, ensure that you have the correct hardware driver level.
You only need to define the LCSS and LPARs (and specify the maximum
devices for the LCSS). The LPAR can be defined with no I/O resources.
I/O configuration definitions can be dynamically added later to a
logical partition (nondisruptively). The newly defined I/O configuration
definition change can be dynamically activated. Note that any z800
or z900 server used as a coupling facility image in this environment
needs to have the CFCC z990 Compatibility MCL installed (see item <a href="#izcfccc">6</a> for details).</p></li>
<li>There is no correlation between LPAR ID and the LCSS under which
an LPAR runs. There can be LPARs in LCSS 0 with LPAR IDs greater than
15, and there can be LPARs in LCSS 1 (and LCSS 2 and LCSS 3) with
LPAR IDs less than or equal to 15.</li>
</ol></div></li>
<li><em>Define channel paths.</em> The processor name
is qualified by the LCSS ID. Channel path IDs (CHPIDs) only need to
be unique within an LCSS.
<div>
<div class="notelisttitle" id="wq155">Notes:</div>
<ol type="a">
<li>There are no default CHPIDs on the machine when configured or
shipped. Physical channel IDs (PCHIDs) must be defined.</li>
<li>Cryptography functions do not require CHPIDs.</li>
<li>Spanned channels access and candidate lists are by LCSS and partition.</li>
<li>The internal queued direct (IQD) CHPID on the VTAM&reg; start option IQDCHPID=<var class="pv">xx</var> must be defined
as a spanned CHPID if communication with systems in other LCSSs is
desired.</li>
</ol></div></li>
<li>Recommended: <em>Use the CHPID Mapping Tool</em> to
map logical CHPIDs to physical channels (PCHIDs) and create input
to HCD/IOCP. The tool is a workstation-based Java application available from the IBM Resource
Link web site: <a href="http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>. <a id="idx233"></a><a id="idx234"></a><a id="idx235"></a>It updates the z990 or z890 IOCP input file
with the &quot;PCHID&quot; keyword and can generate reports to help with
cabling. To obtain and use the tool, do the following:
<ul>
<li>If this is an initial z990 or z890 order, download a machine order
file (CFReport or manufacturing order file) from Resource Link to a workstation.</li>
<li>Create a validated work IODF (an IODF that is valid except that
it is missing PCHIDs) using HCD option 2.12 (Build Validated Work
I/O Definition File).</li>
<li>Create an IOCP deck without PCHIDs or with some PCHIDs missing
using HCD option 2.3 (Build IOCP Input Deck).</li>
<li>Download the IOCP file (which can include PCHID keywords) to the
workstation.</li>
<li>Download the tool.</li>
<li>Run the tool selecting the 2084 hardware configuration file (.hwc
or .cfr) and import the IOCP statements.</li>
<li>Upload the updated IOCP deck with the PCHIDs assigned using HCD
option 5.1 (Migrate IOCP/OS Data). Choose migrate option 3 (PCHIDS).</li>
<li>Build a production IODF.</li>
<li>Write the IOCDS to the z990 or z890 support element using HCD
or stand-alone IOCP.</li></ul></li>
<li><em>Define control units.</em> A control unit is
defined once in the IODF but the CHPID.link combinations for a z990
or z890 processor are defined for each LCSS because each LCSS has
its own set of CHPIDs.</li>
<li><em>Define devices.</em> The channel subsystem
data  (for example, the preferred path and candidate lists) must be
specified for each LCSS (and may be different for each LCSS).</li></ul>
<div>
<div class="notetitle" id="pcffnsu">Note:</div>
<div class="notebody">The following features and functions
are not supported by the z990 and z890 servers:
<ul>
<li>Parallel channels. Use the IBM ESCON Converter or the Optica
Technologies 34600.</li>
<li>OSA-2 adapters. Use the equivalent OSA-Express adapter. (For FDDI,
use a multiprotocol switch or router with the appropriate network
interface.)</li>
<li>OSA-Express ATM adapters. Use a multiprotocol switch or router
with the appropriate network interface, for example, 1000BASE-T or
Gigabit Ethernet.</li>
<li>4-Port ESCON cards. Replace
these with new 16-Port ESCON cards
during upgrade. The 16-Port ESCON card
has a MTRJ-45 connector.</li>
<li>FICON cards (pre-FICON Express). Replace these with FICON Express during upgrade. FICON Express has
a different connector.</li>
<li>PCICC. This feature is replaced with PCIXCC for most of the commonly
used cryptography functions.</li>
<li>Activation of an over-defined channel configuration.</li>
<li>Systems Network Architecture (SNA) Operations Management commands
and SNA based APIs are not supported on z990 and z890 servers. These
commands were previously used by the System Automation for OS/390&reg; product as well as NetView&reg;. It is recommend that
you now use the Simple Network Management Protocol (SNMP) application
programming interfaces (APIs) for your automation needs.</li></ul></div></div></li>
<li id="iz9scso"><strong>Install coexistence software.</strong> <em>All</em> images that share DASD with any z/OS, z/VM, or z/VSE&reg; operating
system images running on a z990 or z890 server need to have ICKDSF
R17 installed. IBM recommends
that ICKDSF R17 be deployed to all other systems that share DASD,
before any z990 or z890 server is brought into use in the sysplex.<a id="idx236"></a><a id="idx237"></a><a id="idx238"></a><a id="idx239"></a><a id="idx240"></a><a id="idx241"></a><a id="idx242"></a><a id="idx243"></a></li>
<li><strong>Plan for coupling facility images.</strong> Coupling
facility images on G2, G3, G4, or equivalent processors cannot be
connected to operating system images on a z990 or z890 server and
therefore any structures in these coupling facility images also need
to be moved to a coupling facility that can connect to this environment
(G5, G6, z800, z900, z990, or z890  server).
<p>Only coupling facility
images on G5, G6, z800, and z900 servers are supported. While z990
and z890 servers do not offer a stand-alone coupling facility option,
you could have a coupling facility image as the only image in the
z990 or z890 server, making it look effectively like a stand-alone
coupling facility, or you could have an ICF image along with other
partitions running z/OS, or
other workloads, on your z990 or z890 server (possibly using coupling
facility duplexing). Alternatively, you can continue to use your existing
z900 or z800 coupling facilities (2064-100) and G5/G6 coupling facilities.
However, workloads such as data sharing, global resource serialization,
and DB2 (users of locking structures)
are likely to require newer technology for performance reasons. If
you have such workloads, you should plan to upgrade G5 coupling facilities
(9672-R06) to z900 coupling facilities, or move your coupling facilities
to z990s or z890s. IBM does <em>not</em> recommend using G5 coupling facilities in
a Parallel Sysplex cluster
with z990 or z890 servers for these workloads. You should only use
them as a temporary migration step.</p></li>
<li id="izcfccc"><strong>Install z990 CFCC coexistence microcode.</strong> If
you intend to have an operating system image or a coupling facility
image on a z990 or z890 server <em>and</em> have more
than 15 LPARs defined (even if 15 or fewer are activated), you need
to have CFCC compatibility code installed on:<a id="idx244"></a><a id="idx245"></a>
<ul>
<li>Any coupling facility image (stand-alone or ICF) on a G5, G6,
z800, or z900 server that will connect to an operating system image
on the z990 or z890 server.</li>
<li>Any coupling facility image (stand-alone or ICF) that will be
duplexed with a z990 or z890 coupling facility image.</li></ul>IBM recommends that the CFCC z990 compatibility MCL be rolled
out on all coupling facility images that will reside on a G5, G6,
z800, or z900 server that will connect to an operating system image
on a z990 or z890 server or be duplexed with a coupling facility image
on a z990 or z890 server, before any z990 or z890 server is brought
into use in the sysplex.
<p></p>
<div>
<div class="notelisttitle" id="wq157">Notes:</div>
<ol type="a">
<li>The CFCC z990 compatibility code is provided with the GA level
of CFCC Level 11 (for G5 and G6 servers) and as an MCL on CFCC Level
12 (for z900 and z800 servers). The CFLEVEL 12 MCL is disruptive,
so IBM recommends that you coordinate
the installation of this MCL with other disruptive MCLs, if possible.</li>
<li>If you are MES-upgrading to a z990 or z890 server, or replacing
(&quot;box swap&quot;) an existing server, then the &quot;old&quot; server does
not require the CFCC compatibility MCL.  However, any remaining G5,
G6, z800, or z900 servers that will be connecting to the z990 or z890
server will require the MCL upgrade (if more than 15 LPARs will be
defined).</li>
<li>If 15 or fewer LPARs will be defined on the z990 or z890 server,
then the CFCC compatibility code is <em>not</em> required
on z900 and z800 servers.  If at any time in the future you define
more than 15 LPARs, then the CFCC compatibility code will be required
at that time.</li>
<li>If you have a coupling facility image (stand-alone or ICF) on
a G5 or G6 server that will either connect to an operating system
image on a z990 or z890 server or be duplexed with a z990 or z890
coupling facility image, then the CFCC level of the G5 or G6 coupling
facility image <em>must</em> be CFCC Level 11 (or later).</li>
<li>If you have a coupling facility image (stand-alone or ICF) on
a z900 or z800 server that will either connect to an operating system
image on a z990 or z890 server or be duplexed with a z990 or z890
coupling facility image, then the CFCC level of the z900 or z800 coupling
facility image <em>must</em> be CFCC Level 12.</li>
</ol></div>
<table id="wq159" width="90%" summary="" border="1" frame="border" rules="all">
<caption>Table 8. Summary of z990 CFCC coexistence support</caption>
<thead valign="bottom">
<tr>
<th id="wq160" align="left" valign="bottom">Server</th>
<th id="wq161" align="left" valign="bottom">CFCC level</th>
<th id="wq162" align="left" valign="bottom">15 or fewer LPARs defined on
a z990 or z890 server</th>
<th id="wq163" align="left" valign="bottom">More than 15 LPARs defined on
a z990 or z890 server</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq160">Pre-G5, G5, or G6</td>
<td headers="wq161">CFCC Level 9 (or below)</td>
<td headers="wq162">Not supported</td>
<td headers="wq163">Not supported</td>
</tr>
<tr>
<td headers="wq160">G5 or G6</td>
<td headers="wq161">CFCC Level 11</td>
<td headers="wq162">Supported</td>
<td headers="wq163">Supported</td>
</tr>
<tr>
<td headers="wq160">z800 or z900</td>
<td headers="wq161">CFCC Level 9 or 10</td>
<td headers="wq162">Not supported</td>
<td headers="wq163">Not supported</td>
</tr>
<tr>
<td headers="wq160">z800 or z900</td>
<td headers="wq161">CFCC Level 12</td>
<td headers="wq162">Supported</td>
<td headers="wq163">Not supported</td>
</tr>
<tr>
<td headers="wq160">z800 or z900</td>
<td headers="wq161">CFCC Level 12 with CFCC compatibility code,
or CFCC Level 13</td>
<td headers="wq162">Supported</td>
<td headers="wq163">Supported</td>
</tr>
</tbody>
</table></li>
<li id="incrswa"><strong>Install cryptographic software,
if necessary.</strong> If you use cryptographic services, ensure that
you have the level of cryptographic support that you require on your z/OS system. For a cross reference
of ICSF FMIDs, web deliverables, and z/OS releases,
see <a href="http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782">http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782</a>.
<div>
<div class="notetitle" id="wq164">Note:</div>
<div class="notebody">The following infrequently used cryptographic functions
that are in z900 and z800 servers are not in z990 and z890 servers:
<ul>
<li>Digital Signature Algorithm support</li>
<li>ANSI x9.17 services and key types</li>
<li>Cipher_Text Translate (CSNBCTT)</li>
<li>German Bank Pool - Pin Offset</li>
<li>CSFUDK  (replaced with CSNBDKG)</li>
<li>Commercial Data Masking Facility (CDMF) - 40-bit Encryption</li></ul></div></div></li></ol>
<h3 id="wq165">Actions you can take when you order a z990 or z890 server</h3>
<p>Determine future target I/O requirements <em>before</em> placing
your order.</p>
<p>If required, use &quot;Plan Ahead&quot; for I/O cages and associated
base infrastructure (adding I/O cages later is disruptive).</p>
<p>PCIXCC installation will be nondisruptive. Use &quot;Plan Ahead&quot; for
the PCIXCC to ensure that slots are reserved in advance. This also
balances the configuration when PCIXCC is available and installed.</p>
<p>Once I/O infrastructure is planned ahead, model upgrades or adding
I/O cards can be nondisruptive, and Self-Timed Interconnect buses
(STIs) are hot-pluggable.</p>
<p>Ensure that proper hardware features are ordered.  For example,
hardware features for cryptography are:</p>
<ul>
<li>PCIXCC (feature code 0868), if required</li>
<li>CP Assist for Cryptographic Functions (CPACF) DES/TDES (feature
code 3863)</li>
<li>PCICA (feature code 0862), if required</li></ul>
<p>Ensure that Driver 55 or later is ordered if you want support for
the following features and functions on the z990 server: </p>
<ul>
<li>Four Logical Channel Subsystems</li>
<li>Spanned external channels</li>
<li>PCIX Crypto Adapter Integrated Console Controller</li>
<li>OSA Integrated Console Control (OSA-ICC)</li>
<li>Extended Translation Facility</li>
<li>System z Application
Assist Processor (zAAP) (requires Driver 55K or later)</li></ul>
<h3 id="aaicore">Actions you can take after you install z/OS for a z990 or z890 server</h3>
<ol type="1">
<li><strong>Update CFRM policies.</strong> 
<p>If a coupling facility
image resides on a G5, G6, z800, or z900 server, then the partition
number currently specified in the CFRM policy is the same as the partition
number defined in HCD. No change is required for the partition number.</p>
<p>If
a coupling facility image resides on a z990 or z890 server, then the
partition number specified in the CFRM policy is the logical partition
identifier specified in the HMC Image Profile (Partition ID).  The
CFRM policy utility was changed to accept a two-digit hexadecimal
PARTITION value for an LPAR ID greater than 15.</p>
<p><strong>Update
CFRM policies.</strong> Coupling facilities are identified in the CFRM
policy by their physical node descriptor information (for example,
machine type, model, serial number, LPAR number). When a coupling
facility undergoes a hardware upgrade, one or more of these pieces
of information is likely to change, therefore, the definition of the
coupling facility in the CFRM policy must change accordingly.</p></li>
<li><strong>Update automation for new and changed messages.</strong>
<p>The
following messages are changed to display two-digit LPAR IDs: IOS431I,
IXC101I, IXC105I, IXC357I, IXC360I, IXC361I, IXC362I, IXC500I, IXC505I,
IXC506I, IXC507I, IXC515I, IXC517I, IXC518I, IXC519E, IXC551I, IXC579I,
IXL008I, IXL010E, IXL141I, IXL150I, IXL157I, IXL158I, IXL160E, and
IOX50xI.</p>
<p>PCHID information is now displayed, when appropriate.</p>
<p>The
following messages are associated with changed command output:</p>
<ul>
<li>IEE174I - display output for D M=CPU command</li>
<li>IOS506I display output for D IOS,CONFIG(HSA) and D IOS,CONFIG(ALL)
command output</li></ul></li>
<li><strong>Notify those affected by changed command output.</strong> Command
syntax is not changed for z990 and z890 support but rather the display
output for the following commands is changed:
<ul>
<li>The D M=CPU command can now display a two-hexadecimal-digit LPAR
ID from partitions running on a z990 or z890 server, which supports
two-digit LPAR IDs. (The message number is IEE174I.) The logical CPU
address no longer appears in the CPU ID. CSS ID, MIF ID, and the like
are now formatted.</li>
<li>The D IOS,CONFIG(HSA) command will display zeros for the unshared
subchannel and logical CUs lines in the message. (The message number
is IOS506I.) On z/OS V1R5 and
later, subchannel and logical CUs will be displayed by LCSS.</li>
<li>The D M=CHP command is changed to add PCHID to the display.</li>
<li>The D CF command is changed to support two-hexadecimal-digit LPAR
IDs and PCHIDs.</li>
<li>The D XCF command is changed to support two-hexadecimal-digit
LPAR IDs.</li></ul></li>
<li><strong>Modify programs affected by changed SMF records.</strong> If
you currently process SMF records 70, 74, 79, and 89, you will need
to review changes and modify any user-written programs if they are
affected. The changes are:<a id="idx246"></a>
<ul>
<li>SMF Record 70 Subtype 1 (CPU and PR/SM&trade; Activity)
is now split into multiple records if the number of LPARs and CPs
requires more than 32K. Each piece is self-containing, that is, records
can be processed without reassembling the broken pieces.</li>
<li>SMF Record 74 Subtype 1 (Device Activity) is changed because of
I/O architecture.</li>
<li>SMF Record 79 Subtype 9 (Device Activity) is changed because of
I/O architecture.</li>
<li>SMF Record 89 (product usage data) is changed to support 4-bit
and 8-bit LPAR identifiers and more than 15 LPARs.</li>
<li>SMF Record 99 Subtype 8 (WLM LPAR Management - CPU Period
Table Entry) is changed to add the CSS ID.</li>
<li>SMF Record 99 Subtype 9 (I/O Subsystem Info - Channel Path
Data Entry) is changed to add the CSS ID.</li></ul></li>
<li><strong>Update parmlib members.</strong> Review parmlib changes
and update members as appropriate:
<ul>
<li>If you use cryptography, then you should be aware that ICSF provides
IPCS support. A parmlib member, CSFIPCSP, will be installed into the
library specified on the SMP/E PARMLIB DDDEF statement (and delivered
in SYS1.IBM.PARMLIB in ServerPac). Ensure that this library is included
in your IPCS concatenation. If you copy members from that library
to another library, you have to copy CSFIPCSP.<a id="idx247"></a><a id="idx248"></a></li>
<li>There is no change to member SMFPRM<var class="pv">xx</var>. However, there
is a change in the description of the serial number in the SID parameter
when a z990 or z890 is involved; the first two digits are the LPAR
ID instead of the logical CPU address and LPAR ID.</li></ul></li>
<li><strong>Modify programs affected by macro changes.</strong> As
with any software upgrade, you need to review any macro changes and
update any user programs if they are affected.</li></ol>
<h3 id="wq167">Actions you might need to take once you are using a z990 or
z890 server</h3>
<p>ACTIVATE actions:</p>
<ul>
<li>You can perform a software ACTIVATE (the number of defined LCSSs
is irrelevant).</li>
<li>You can only perform a hardware ACTIVATE if the changed or new
resources are restricted to LCSS 0.</li>
<li>A power-on reset is required when adding or removing an LCSS,
changing the maximum number of devices for an LCSS, adding or deleting
LPARs, and adding or changing a resource in an LCSS other than LCSS
0.</li>
<li>You can perform full hardware or software ACTIVATE (regardless
of the LCSS where the new or changed resources are defined).</li></ul>
<p>Be aware that removing (restoring) the CFCC compatibility code
from a G5, G6, z800, or z900 server will reintroduce sysplex coexistence
considerations. That is, removing the CFCC compatibility support from
a coupling facility image elsewhere in the sysplex will prohibit that
coupling facility from participating in a sysplex with operating system
or coupling facility images on a z990 or z890 with more than 15 LPARs
defined on it (regardless of the number of LPARs that are activated).</p>
<h2 id="at3ruio">Replace unsupported devices</h2>
<p><strong>Description:</strong> You should remove and replace
devices that were supported by earlier releases but cannot be used
with the current release of z/OS because
they are no longer supported.<a id="idx249"></a><a id="idx250"></a></p>
<table id="wq168" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use any of the devices that are
no longer supported.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>Replacement devices as necessary.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Determine whether the devices you use are supported. A list of
supported I/O devices is in the topic about <a href="../com.ibm.zos.r13.e0zb100/devsupt.htm">identifying I/O device requirements</a> in >z/OS Planning for Installation</a>.
If you have a question about support for any devices not listed, contact
your IBM representative.</li>
<li>Install replacement devices. Move data that is stored on unsupported
devices to the supported devices. Detach unsupported devices from
the system and delete their corresponding device definitions from
the input/output definition file (IODF).</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For a list of I/O devices that are supported, see the topic about <a href="../com.ibm.zos.r13.e0zb100/devsupt.htm">identifying I/O device requirements</a> in >z/OS Planning for Installation</a>.</li>
<li>For information about deleting device definitions from
the IODF, see >z/OS HCD User&rsquo;s Guide</a>.</li></ul>
<h2 id="au3ndv">Provide for new device installations</h2>
<p><strong>Description:</strong> The hardware configuration of
your processors and I/O devices determines how many devices you can
attach to your system. z/OS supports
attachment of up to 65,280 devices, each with up to eight access paths. <a id="idx251"></a></p>
<table id="wq170" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are going to use new devices with z/OS V1R11 and later.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>Dependent upon the new devices used.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> The following are general
considerations related to I/O device support. </p>
<ul>
<li><em>Attaching devices through HCD.</em> You can
define, or attach, new devices to your system through the interactive
panels of the Hardware Configuration Definition (HCD) base element.
HCD has dynamic I/O capabilities, changing hardware definitions without
the need for an IPL or hard power-on reset. 
<p>Any time you make changes
to your I/O configuration, you need to use HCD to modify your system's
I/O definition file (IODF). You should also update the input/output
configuration data set (IOCDS) when you run HCD to ensure that the
configuration information is consistent across the software and microcode.</p></li>
<li><em>Operating modes.</em> Most devices attached
to z/OS operate in full function
mode, that is, all features on the device are compatible with, and
usable on, the operating system. Some of these features include:
<ul>
<li>For DASD devices: dynamic path reconnection, extended count-key-data
operation, and caching and cache-related facilities</li>
<li>For tape devices: cartridge stack loading and data compaction</li></ul>
<p>Some devices also operate in compatibility mode, which allows
you to simulate the function of another device or model. Compatibility
mode causes the device to function like a different device of the
same type, ignoring some or all of the additional features the device
might have. This allows you to migrate between devices with minimal
impact on programs that have device dependencies.</p></li>
<li><em>UCB virtual storage constraint relief.</em> Each
device attached to the system has one or more UCBs associated with
it. You have the option to define UCBs either above or below the 16
MB line by specifying the LOCANY parameter on the Hardware Configuration
Definition (HCD) panel. The system programmer should review the contents
of the link pack area (LPA) list to determine whether to remove or
move libraries to gain virtual storage constraint relief.<a id="idx252"></a><a id="idx253"></a></li>
<li><em>Hardware maintenance.</em> Some devices require
a specific level of hardware maintenance to operate properly on a z/OS system. DFSMS software support for new
hardware devices might also require the installation of PTFs.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For a summary of the most commonly-used I/O devices supported
by z/OS that are also directly
supported by DFSMS functions,
see the topic about <a href="../com.ibm.zos.r13.e0zb100/devsupt.htm">identifying
I/O device requirements</a> in >z/OS Planning for Installation</a>.
 If you have a question about support for a device that is not listed,
contact your IBM representative.</li>
<li>For more information about HCD, see >z/OS HCD Planning</a>.</li>
<li>For information about working with IODFs, see >z/OS HCD User&rsquo;s Guide</a>.</li></ul>
<h2 id="au3cpfl">Update your CFRM policy with coupling facility structure size
changes</h2>
<p><strong>Description:</strong> If you are migrating to a new
level of coupling facility control code (CFCC), you have to make appropriate
coupling facility structure size updates in the z/OS coupling facility resource management (CFRM)
policy.</p><a id="idx254"></a><a id="idx255"></a><a id="idx256"></a>
<table id="wq171" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are migrating to a new CFCC level.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>See <a href="http://www.ibm.com/systems/z/pso/cftable.html">http://www.ibm.com/systems/z/advantages/pso/cftable.html </a>.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you are migrating to a
new CFCC level, do the following: </p>
<ol type="1">
<li>Run the Coupling Facility Structure Sizer (CFSizer) tool. This
tool sizes structures, taking into account the amount of space needed
for the current CFCC levels. The tool sizes for the most currently
available level; you might find that the results are oversized if
you use an earlier CFCC level. You can find the tool at <a href="http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.<a id="idx257"></a><a id="idx258"></a><a id="idx259"></a>
<p>Alternatively, you can run an as-is batch utility
program called SIZER after you have brought a new CFLEVEL coupling
facility into use in your configuration. SIZER examines your currently
allocated coupling facility structures and recalculates the size that
should be used for them with the new later-CFLEVEL coupling facility.
The as-is SIZER utility is available as a zipped package that
you can download from <a href="http://www.ibm.com/systems/support/z/cfsizer/altsize.html">http://www.ibm.com/systems/support/z/cfsizer/altsize.html </a>.</p></li>
<li>Update the CFRM policy with the size modifications that are needed.</li>
<li>Activate the updated CFRM policy so that it becomes the active
policy governing structure allocation in the sysplex.</li></ol>
<p><strong>Reference information:</strong> For a detailed description
of coupling facility code levels and the processors that support those
levels, see <a href="http://www.ibm.com/systems/z/pso/cftable.html">http://www.ibm.com/systems/z/advantages/pso/cftable.html </a>.<a id="idx260"></a><a id="idx261"></a><a id="idx262"></a></p>
<h2 id="sttostp">Migrate from a Sysplex
Timer to STP</h2>
<p><strong>Description:</strong> The Server Time Protocol
(STP) feature is the follow-on to the Sysplex Timer (9037-002). STP is designed to allow
multiple servers and coupling facilities to maintain time synchronization
with each other, without requiring a Sysplex Timer. STP is a hardware feature of the zEC12,
z196, <span>z114</span>, z10 EC, z10 BC, z9 EC, z9 BC, z990, and z890.<a id="idx263"></a><a id="idx264"></a></p>
<table id="wq173" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>STP was announced on 27 July 2005 in the z9 EC announcement (US letter 105-241)
and on 10 October 2006 in the STP announcement (US letter 106-715).
STP became generally available in January 2007.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>
<ul>
<li>Yes, if you are planning to use a zEC12, z196, or
z114 server because the Sysplex
Timer (9037-002) is not supported with these servers.
<div>
<div class="notetitle" id="wq174">Note:</div>
<div class="notebody"> You do not need an STP-only configuration with
a zEC12, z196 or z114 server. The z196 and z114 servers can participate
in a Mixed-CTN configuration if the other servers connect to
an ETR and are STP enabled. The other server becomes the stratum 1
server for the Mixed-CTN and the zEC12, z196, and z114 servers
connect to the stratum 1 server using coupling link technology.</div></div></li>
<li>No, but recommended if you are using a System z10 or earlier server because these are the last
servers that will support the Sysplex
Timer (9037-002).</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware
requirements:</strong></td>
<td>The servers and coupling facilities that are
capable of supporting STP are the zEC12, z196, <span>z114</span>,
Systems z10 EC, z10 BC, z9 EC, z9 BC, z990, and z890. The STP feature
number is 1021.
<p>STP is a server-wide facility that is implemented
in the Licensed Internal Code (LIC) of the zEC12, z196, <span>z114</span>,
Systems z10 ECs, z10 BCs, z9 ECs, z9 BCs, z990s, z890s, and coupling
facilities, and presents a single view of time to PR/SM.</p>
<p>The Sysplex Timer's LIC has been upgraded
to support using STP in a Mixed Coordinated Timing Network (CTN).
The required Sysplex Timer LIC
is shipped along with the STP feature and must be installed by the IBM Service Support Representative
prior to migrating from a Sysplex
Timer based External Time Reference (ETR) network to any STP
Coordinated Timing Network (CTN).</p></td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>Even though z/OS has
function to support STP, additional PTFs are required. Consult
the PSP buckets for STP-related maintenance. Use FIXCAT IBM.Device.Server.<var class="pv">device-type</var>.ServerTimeProtocol
to get this information.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use ZOSMIGREC_SUP_TIMER_INUSE on z/OS V1R11 or later to determine
whether the timing mode on the current system is ETR.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To implement STP, see the
STP web site and the publications and other resources that are listed
there. The STP web site is at <a href="http://www.ibm.com/systems/z/advantages/pso/stp.html">http://www.ibm.com/systems/z/advantages/pso/stp.html </a>.</p>
<p><strong>Reference information:</strong> See &quot;Steps to take&quot; above.</p>
<h2 id="phoicb4">Migrate from ICB-4 to Infiniband coupling links</h2>
<p><strong>Description:</strong> System z10 is the last server to support Integrated Cluster
Bus-4 (ICB-4) links. IBM does
not intend to offer ICB-4 links on future servers.</p>
<table id="wq175" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The intention to not offer ICB-4 links on future
servers was originally stated in the IBM System z10 EC announcement on 26 February
2008.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration
action required?</strong></td>
<td>
<ul>
<li>Yes, if you are planning to use a zEC12, z196, or
z114 server because ICB-4 links are not offered with these
servers.</li>
<li>No, but recommended if you are using a System z10 or earlier server because these are the last
servers to offer ICB-4 links.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use InfiniBand coupling links
instead of ICB-4 links. Updates to zEnterprise Parallel Sysplex coupling connectivity allow attachment
between zEnterprise and
System z10 and System z9 general purpose servers (no longer
just standalone coupling facilities) using 12X InfiniBand attachment
at 6 gigabytes per second (Gbps). <span>If a zEC12, z196,
z114, z10 EC, or z10 BC server is attached to a z9 EC or z9 BC
server, they operate at 3 gigabytes per second (Gbps) using 12X IFB.</span> InfiniBand
coupling can provide significantly improved service times compared
to ISC-3 for distances up to 150 meters.</p>
<p><strong>Reference information:</strong> You can read about
InfiniBand coupling links in <cite>IBM System z Connectivity Handbook</cite>, SG24-5444.</p>
<h1 id="av1pars">Sysplex migration actions</h1>
<p>This topic summarizes actions for you to take if you are migrating
systems that are members of a base sysplex or Parallel Sysplex configuration.</p><a id="idx265"></a>
<h2 id="wq176">Sysplex actions related to hardware upgrades</h2>
<table id="wq177" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq178" width="75%" align="left" valign="top">Title of migration action</th>
<th id="wq179" width="25%" align="left" valign="top">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq178"><a href="#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
<td headers="wq179"><a href="#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#sttostp">Migrate from a Sysplex
Timer to STP</a></td>
<td headers="wq179"><a href="#sttostp">Migrate from a Sysplex
Timer to STP</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#phoicb4">Migrate from ICB-4 to Infiniband coupling links</a></td>
<td headers="wq179"><a href="#phoicb4">Migrate from ICB-4 to Infiniband coupling links</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#mignext">Migrate to an IBM zEnterprise z196 or z114
server</a></td>
<td headers="wq179"><a href="#mignext">Migrate to an IBM zEnterprise z196 or z114
server</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#migrz10">Migrate to a System z10 server</a></td>
<td headers="wq179"><a href="#migrz10">Migrate to a System z10 server</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#mtodanu">Migrate to a System z9 server</a></td>
<td headers="wq179"><a href="#mtodanu">Migrate to a System z9 server</a></td>
</tr>
<tr>
<td headers="wq178"><a href="#mtoz990">Migrate to a z990 or z890 server</a></td>
<td headers="wq179"><a href="#mtoz990">Migrate to a z990 or z890 server</a></td>
</tr>
</tbody>
</table>
<h2 id="wq180">Sysplex actions to perform before installing z/OS V1R13</h2><a id="idx266"></a><a id="idx267"></a><a id="idx268"></a><a id="idx269"></a><a id="idx270"></a>
<table id="wq181" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq182" width="25%" align="left" valign="bottom">Element or feature</th>
<th id="wq183" width="60%" align="left" valign="bottom">Title of migration action</th>
<th id="wq184" width="15%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq182">Multiple</td>
<td headers="wq183"><a href="#coxptfs">Install coexistence and fallback PTFs</a></td>
<td headers="wq184"><a href="#coxptfs">Install coexistence and fallback PTFs</a></td>
</tr>
<tr>
<td headers="wq182">DFSMSdfp</td>
<td headers="wq183"><a href="#ax3eisc">DFSMSdfp:
Back up SMS control data sets</a></td>
<td headers="wq184"><a href="#ax3eisc">DFSMSdfp:
Back up SMS control data sets</a></td>
</tr>
<tr>
<td headers="wq182">Distributed File Service</td>
<td headers="wq183"><a href="#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
<td headers="wq184"><a href="#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
</tr>
</tbody>
</table>
<h2 id="wq185">Sysplex actions to perform before the first IPL of z/OS V1R13</h2><a id="idx271"></a><a id="idx272"></a><a id="idx273"></a><a id="idx274"></a><a id="idx275"></a><a id="idx276"></a><a id="idx277"></a>
<table id="wq186" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq187" width="25%" align="left" valign="bottom">Element or feature</th>
<th id="wq188" width="60%" align="left" valign="bottom">Title of migration action</th>
<th id="wq189" width="15%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq187">BCP</td>
<td headers="wq188"><a href="#oa35357">Change value for ARM restart processing</a></td>
<td headers="wq189"><a href="#oa35357">Change value for ARM restart processing</a></td>
</tr>
<tr>
<td headers="wq187">BCP</td>
<td headers="wq188"><a href="#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
<td headers="wq189"><a href="#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
</tr>
<tr>
<td headers="wq187">BCP</td>
<td headers="wq188"><a href="#operloge">Accommodate OPERLOG EMCS console name change</a></td>
<td headers="wq189"><a href="#operloge">Accommodate OPERLOG EMCS console name change</a></td>
</tr>
<tr>
<td headers="wq187">BCP</td>
<td headers="wq188"><a href="#sfmpoli">Update the SFM policy to control automatic termination of impaired
critical members</a></td>
<td headers="wq189"><a href="#sfmpoli">Update the SFM policy to control automatic termination of impaired
critical members</a></td>
</tr>
<tr>
<td headers="wq187">JES3</td>
<td headers="wq188"><a href="#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
<td headers="wq189"><a href="#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
</tr>
<tr>
<td headers="wq187">BCP</td>
<td headers="wq188"><a href="#xesfieldlen">Review changes to XES Event Exit Parameter List (IXLYEEPL)
field length</a></td>
<td headers="wq189"><a href="#xesfieldlen">Review changes to XES Event Exit Parameter List (IXLYEEPL)
field length</a></td>
</tr>
</tbody>
</table>
<h2 id="wq190">Sysplex actions to perform after the first IPL of z/OS V1R13</h2><a id="idx278"></a><a id="idx279"></a><a id="idx280"></a><a id="idx281"></a><a id="idx282"></a><a id="idx283"></a><a id="idx284"></a>
<table id="wq191" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq192" width="25%" align="left" valign="bottom">Element or feature</th>
<th id="wq193" width="60%" align="left" valign="bottom">Title of migration action</th>
<th id="wq194" width="15%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq192">BCP</td>
<td headers="wq193"><a href="#grsficon">Migrate to GRS-managed FICON CTCs</a></td>
<td headers="wq194"><a href="#grsficon">Migrate to GRS-managed FICON CTCs</a></td>
</tr>
<tr>
<td headers="wq192">SDSF</td>
<td headers="wq193"><a href="#wbmqsdsf">Update configuration for sysplex support</a></td>
<td headers="wq194"><a href="#wbmqsdsf">Update configuration for sysplex support</a></td>
</tr>
</tbody>
</table>
<h1 id="aa1bcp">BCP migration actions</h1>
<p>This topic describes migration actions for the base element BCP
(Base Control Program).</p><a id="idx285"></a>
<h2 id="wq195">BCP actions to perform before installing z/OS V1R13</h2>
<p>This topic describes BCP migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p><a id="idx286"></a><a id="idx287"></a><a id="idx288"></a><a id="idx289"></a>
<h3 id="edumpds">Evaluate your stand-alone dump data set allocations and your
IPCS processing of them</h3>
<p><strong>Description:</strong> As your applications grow in
size and use ever greater amounts of storage, you should evaluate
whether the DASD allocated for your stand-alone dump data continues
to be adequate. <a id="idx290"></a><a id="idx291"></a></p>
<p>In z/OS V1R6, support was
introduced for extended-format sequential data sets, a form
of data set that is SMS-managed and can occupy more than 64 K tracks
per volume. In z/OS V1R7, this
support was supplemented with support for large format sequential
data sets (DSNTYPE=LARGE), a form of data set that is essentially
the same as conventional sequential data sets except that more than
64 K tracks may be spanned per volume. If your stand-alone dump data
sets are spread over more volumes than you want, both types of support
can help you gain better control over the number of volumes used for
each stand-alone dump data set.</p>
<table id="wq196" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because of changes that
have been made to stand-alone dump processing (that reorder dump records
with the intent of recording more important data early), and especially
recommended if you deploy any LPARs with significantly more main storage
than previously used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Use multivolume stand-alone dump data sets. Adjust the number
of volumes and their separation to achieve tolerable stand-alone dump
capture times.</li>
<li>Use extended-format sequential data sets or large format
sequential data sets. Copy their contents to an extended-format,
compressed, striped data set using the IPCS COPYDUMP subcommand prior
to analysis. Use the same or a larger striping factor than you used
for your stand-alone dump data sets. Dump data sets to which stand-alone
dump can write may be neither compressed nor striped, but both attributes
are advantageous for the target of the copy operation. Starting
with z/OS V1R12, stand-alone
dump data sets can be placed in track-managed space as well
as cylinder-managed space on Extended Address Volumes (EAV).</li>
<li>Use a large CISIZE and striping for IPCS dump directories, and
use blocking, striping, and compression for the stand-alone dump data
set. Very large stand-alone dumps might require that you define your
directory with the extended addressing attribute, allowing it to hold
more than 4 GB.
<p><strong>Tips:</strong> Control interval sizes
less than 24K have been shown to be more vulnerable to fragmentation
when used as IPCS dump directories, and IPCS performance can be degraded
when such fragmentation occurs. In this background, warning message
BLS21110I will be issued and you might recreate the DDIR by using
the CLIST BLSCDDIR.</p>
<pre class="xmp"><code>BLS21110I CISIZE(cisize) is less than 24K. It may degrade IPCS performance</code></pre></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For information about dump data set allocation, extended-format
sequential data sets, large format sequential data sets, and multivolume
dump data sets, see >z/OS MVS Diagnosis: Tools and Service Aids</a>.</li>
<li>For <a href="../com.ibm.zos.r13.e0zk100/bestpr.htm">stand-alone
dump best practices</a>, see >z/OS Problem Management</a>.</li></ul>
<h3 id="warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</h3>
<p><strong>Description:</strong>  Starting in z/OS V1R13 (and rolled back to z/OS V1R12 and z/OS V1R11
in OA35929), you can specify the WARNUND statement in IEASYS<var class="pv">xx</var>.
 When used, this statement indicates that warning message IEA660I
be issued when undefined statements are encountered, rather than prompting
for a correct statement.  Usage of WARNUND can be particularly useful
when specifying new parmlib options in IEASYS<var class="pv">xx</var> (such as
the new IXGCNF and CATALOG system parameters which are introduced
in z/OS V1R13), and allowing
these new IEASYS<var class="pv">xx</var> specifications to be shared with pre-z/OS
V1R13 systems.<a id="idx292"></a><a id="idx293"></a></p>
<table id="wq197" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13,
and rolled back to z/OS V1R12
and z/OS V1R11 with APAR OA35929.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> No, but recommended to assist in sharing IEASYS<var class="pv">xx</var> members
between z/OS V1R13, and pre-z/OS
V1R13 systems, when new enhancements in z/OS V1R13
are to be exploited.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td> Ensure the PTF for APAR OA35929 is installed
on all pre-z/OS V1R13 systems so that the WARNUND statement can be
identified and processed correctly.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>Certain restrictions are identified when using
WARNUND in IEASYS<var class="pv">xx</var>.  See reference information below.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Install the PTF for APAR OA35929 on all pre-z/OS V1R13 systems.</li>
<li>As you add new statements in IEASYS<var class="pv">xx</var> for functional
exploitation and you wish to share those modified IEASYS<var class="pv">xx</var> members
with pre-z/OS V1R13 systems, add <strong>WARNUND</strong> to
the beginning of IEASYS00 as that will cover updates in all IEASYS<var class="pv">xx</var> members.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS MVS System Messages, Vol 6 (GOS-IEA)</a>.</li>
<li><cite></cite>.</li>
<li>Documentation in the PTFs for APAR OA35929.</li></ul>
<h3 id="dasdpfa">Define DASD storage for Predictive Failure Analysis</h3>
<p><strong>Description:</strong> Before z/OS V1R13, Predictive Failure Analysis (PFA) did
not document the requirement for additional DASD storage to accommodate
check output. Starting with z/OS V1R13, >z/OS Problem Management</a> contains
DASD requirements to ensure PFA has enough space to update and create
files in the z/OS UNIX file system to store check
output. In addition, because zFS no longer stores data in 1K fragments,
zFS for z/OS V1R13 might need
more DASD storage to store the same amount of data than was required
in previous releases. For additional information about zFS requirements,
see <a href="#newdasd">zFS: Accommodate new DASD space requirements</a>.<a id="idx294"></a><a id="idx295"></a><a id="idx296"></a><a id="idx297"></a></p>
<table id="wq199" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use PFA.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Define additional DASD storage
for PFA. The total space for the PFA file system for each LPAR depends
on the release of z/OS you
are running.  </p>
<dl>
<dt class="bold">z/OS V1R11 (HBB7760) </dt>
<dd>200 cylinders primary; 50 cylinders secondary on a 3390 device.
</dd>
<dt class="bold">z/OS V1R12 (HBB7770) </dt>
<dd>200 cylinders primary; 50 cylinders secondary on a 3390 device.
</dd>
<dt class="bold">z/OS V1R13 (HBB7780) </dt>
<dd>300 cylinders primary; 50 cylinders secondary on a 3390 device.
</dd>
</dl>
<p><strong>Reference information:</strong> For additional information
and storage requirements for earlier z/OS releases,
see <a href="../com.ibm.zos.r13.e0zk100/iplpfa.htm">Steps for installing PFA</a> in >z/OS Problem Management</a>.</p>
<h3 id="sodbcpii">Migrate from SNMP to z/OS BCPii
for communication to the HMC or SE</h3><a id="idx298"></a><a id="idx299"></a>
<p><strong>Description:</strong> IBM intends
for z/OS V1R13 to be the final
release in which SNMP as supported protocol for the communication
to the Hardware Management Console (HMC) or Support Element (SE) is
available. If you are currently using SNMP for the communication from
the Capacity Provisioning Manager to SE/HMC, it is recommended that
you migrate to BCPii.</p>
<table id="wq200" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the migration to
BCPii will be required in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ul>
<li>You can use the tracking facility to help with this migration
action. In tracking facility output, look for violations that start
with CPO-W:SNMP usage <var class="pv">domain name</var>, where <var class="pv">domain name</var> is
replaced with the actual name of the affected domain. Exploit the z/OS tracking facility on z/OS V1R12 or z/OS V1R11 by installing the PTF for APAR OA35284. If
you are using the tracking facility and have no instances of affected
domains after starting Capacity Provisioning Manager, then this migration
action is not applicable to you.</li>
<li>Set up BCPii as described in >z/OS MVS Programming: Callable Services for High-Level Languages</a>.</li>
<li>Define the required security profiles to allow the Capacity Provisioning
Manager user to access the hardware information.</li>
<li>Add the Topology.Protocol=INTERNAL key to the Capacity Provisioning
Manager parameter file. Using the default values, the file is the
member CPO.DOMAIN1.PARM(PARM).</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For information about BCPii setup, see >z/OS MVS Programming: Callable Services for High-Level Languages</a>.</li>
<li>For information about required security profile and how to define
the new key to the Capacity Provisioning Manager parameters, see >z/OS MVS Capacity Provisioning User&rsquo;s Guide</a>.</li>
<li>For information about using the tracking facility, see &quot;Appendix
A. Tracking facility" in >z/OS MVS Planning: Operations</a>.</li></ul><a id="idx300"></a>
<h3 id="oneblank">Verify that at  least one blank follows all major keyword statements
in CONSOLExx</h3>
<p><strong>Description:</strong> Before z/OS V1R13, you could specify INIT, DEFAULT,  HARDCOPY
and CONSOLE keyword statements without using a blank delimiter. This
can cause a problem if other keywords are misplaced or misspelled.
For example, if INTIDS(Y) is misspelled as INITIDS(Y), the parser
considers this an INIT statement. This could result in a console not
being defined correctly, or even having a system with no consoles
after initialization except the system console.</p>
<p>Starting with z/OS V1R13,
if you do not have a blank character after the four major keywords
(INIT, DEFAULT, HARDCOPY, and CONSOLE), <span>you will receive
a syntax error during CONSOL<var class="pv">xx</var> parmlib processing indicated
by message IEA195I or message IEA196I</span> as shown in the example
below:</p>
<pre class="xmp"><code>- IEA196I CONSOLM1 03E0: NAME REQUIRED FOR CONSOLE.
- IEA196I CONSOLM1 INIT: DUPLICATE SPECIFICATION IGNORED.
- IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
- IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
- IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.
- IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.</code></pre><p class="indatacontent">Also,
if you do not have a blank after the major keywords INIT,  DEFAULT,
and HARDCOPY, the default values will be used.  In the case of the
major keyword, CONSOLE, you will be left with only the system console
if all of your CONSOLE statements do not end with a blank characters.</p>
<table id="wq201" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td> BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not have at least one blank after
any of the four major keywords INIT, DEFAULT, HARDCOPY, and CONSOLE.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Examine your CONSOL<var class="pv">xx</var> parmlib member to verify that you
have at least one blank after all of your major keyword statements.</li>
<li>If, you do not have a blank, update your CONSOL<var class="pv">xx</var> parmlib
member by entering one or more blanks between the major keyword statements
and their associated keywords.</li></ol>
<p><strong>Reference information:</strong> For more information
about the CONSOL<var class="pv">xx</var>  parmlib member, see >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h3 id="cplibpath">Upgrade Java support
for Capacity Provisioning</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, the Provisioning Manager component of
Capacity Provisioning requires Java V6.0.
If the references in the ENV member of the Provisioning Manager parameters
dataset specify the location of an earlier version of Java, you must update the LIBPATH
environment variable.<a id="idx301"></a><a id="idx302"></a></p>
<table id="wq203" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>IBM 31-bit
SDK for z/OS, Java Technology Edition, V6 (5655-R31).</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ul>
<li>Install IBM 31-bit SDK for z/OS, Java 2
Technology Edition, V6 (5655-R31).</li>
<li>Change the LIBPATH variable in the ENV member of your Provisioning
Manager <span>PARM data set to point to</span> the installation
directories of your Java V6
installation. LIBPATH statement may look like:
<pre class="xmp"><code>LIBPATH=/usr/lib:/usr/lpp/java/J6.0/bin:usr/lpp/java/J6.0/bin/classic:
        /usr/lpp/cpo/lib</code></pre></li></ul>
<p><strong>Reference information:</strong> For information about
how to adapt the Provisioning Manager parameters, see >z/OS MVS Capacity Provisioning User&rsquo;s Guide</a></p>
<h3 id="pgserpro">Discontinue use of PGSER to protect and unprotect the READONLY
nucleus</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, most of the READONLY nucleus is backed
by 1 MB pages. This makes protecting or unprotecting the READONLY
nucleus with the PGSER macro difficult because the macro can only
handle virtual storage pages backed by 4 KB pages. Therefore, the
PGSER macro is changed, with APAR OA33782, to no longer support requests
to protect and unprotect the READONLY nucleus if it is backed by 1
MB pages.<a id="idx303"></a></p>
<table id="wq204" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13. z/OS V1R12 by APAR OA33782.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
without APAR OA33782, and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the PGSER macro to protect or
unprotect the READONLY nucleus.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to discontinue use of PGSER to protect
and unprotect READONLY nucleus that is backed by 1 MB pages will result
in the ABEND18A reason codes indicated in &quot;Steps to take,&quot;
below.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Do not use PGSER to protect
or unprotect the READONLY nucleus when it is backed by 1 MB pages.
 Users requiring the modification of READONLY  nucleus should use
the DATOFF macro.</p>
<p>Failure to discontinue use of PGSER to protect and unprotect READONLY
nucleus that is backed 1 MB pages will result in the following ABEND18A
reason codes:</p>
<ul>
<li>FF070411- The caller issued a PGSER macro with the PROTECT
parameter for virtual storage in the READONLY nucleus that is backed
by 1 MB pages. This storage area cannot be specified with the PROTECT
keyword.</li>
<li>FF080411 - The caller issued a PGSER macro with the UNPROTECT
parameter for virtual storage in the READONLY nucleus that is backed
by 1 MB pages. This storage area cannot be specified with the UNPROTECT
keyword.</li></ul>
<p><strong>Reference information:</strong> For detailed information
about PGSER, see  >z/OS MVS Programming: Authorized Assembler Services Reference LLA-SDU</a>.</p>
<h3 id="xesfieldlen">Review changes to XES Event Exit Parameter List (IXLYEEPL)
field length</h3>
<p><strong>Description:</strong> In z/OS V1R13 the length of the field EEPLEVENTSPECIFICINFO
in the XES Event Exit Parameter List (IXLYEEPL) is being increased
by 8 bytes to include additional information for users to take advantage
of the new function provided by greater-than-32 connectors. This additional
information is mapped by EEPLSTRSTATECHANGEINFO.  The following fields
have been added to the EEPLSTRSTATECHANGEINFO mapping:</p>
<ul>
<li>EEPLSSCSTRFACILITYUSERLIMIT</li>
<li>EEPLSSCSTRLOCKNUMUSERS</li></ul><p class="indatacontent">A program can determine if these fields are valid; therefore,
you can use the longer length for EEPLEVENTSPECIFICINFO if the flag
EEPLSSCUSERLIMITINFOVALID is set. This change was rolled back to z/OS V1R10  in the service stream
through APAR OA34061.<a id="idx304"></a></p>
<table id="wq205" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
with APAR OA34061 (rolled back to z/OS V1R10).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13, z/OS V1R12, and z/OS V1R11 without APAR OA34061.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if any of your programs have relied on
the length field of EEPLEVENTSPECIFICINFO in IXLYEEPL.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>CFLEVEL 17 support for greater-than-32 connectors
for list/lock structures.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Consider any program that
makes use of the length field EEPLEVENTSPECIFICINFO in IXLYEEPL. If
you rely on the length of field  EEPLEVENTSPECIFICINFO, for example
if its length is used to define local data areas in a module and if
the length that the compiler uses will be the updated larger length,
all modules using the length of the field need to be recompiled.</p>
<p><strong>Reference information:</strong> For details, see <cite> z/OS MVS Data Areas, Volume 2</cite>,
GA32-0854..</p>
<h3 id="remrtls">Track CSVRTLS services</h3>
<p><strong>Description:</strong> z/OS V1R5
was the last release of z/OS to
support Run-Time Library Services (RTLS) for Language Environment.
In z/OS V1R12, the underlying
CSVRTLS services were removed from z/OS.
A way to track CSVRTLS usage, and to let you find any programs that
might be using these services, is available in z/OS V1R11, and rolled back to z/OS V1R10 with APAR OA29019.<a id="idx305"></a><a id="idx306"></a></p>
<table id="wq206" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
with APAR OA29995.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using CSVRTLS services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>As of z/OS V1R12,
failure to remove references to the SET RTLS or DISPLAY RTLS command
will result in error messages indicating the entry is unknown or not
supported, as shown below:
<pre class="xmp"><code>IEE309I SET      UNIDENTIFIABLE KEYWORD  
IEE305I DISPLAY  COMMAND INVALID </code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Exploit the z/OS tracking
facility to help determine if you are using any of the CSVRTLS services
(SET RTLS command, DISPLAY RTLS command, CSVRTLS macro, and RTLS system
parameter in IEASYS<var class="pv">xx</var> parmlib member) removed from z/OS V1R12:
<ul>
<li>For z/OS V1R11, install
PTF UA49184 for APAR OA29995.</li></ul></li></ul>
<p><strong>Reference information:</strong></p>
<ul>
<li>See APAR OA29995.</li>
<li>To learn more about the tracking facility, see Appendix A in >z/OS MVS Planning: Operations</a>.</li>
<li>To activate or deactivate the tracking facility, use the SETCON
TRACKING command. When you activate the OPERCMDS FACILITY class, you
must have the CONTROL access authority to the profile when issuing
the SETCON TRACKING command. For information about this command, see >z/OS MVS System Commands</a>.</li>
<li>To display the recorded events, use the DISPLAY OPDATA,TRACKING
command. For information about this command, see >z/OS MVS System Commands</a>.
This command  displays message CNZ1001I. For information about this
message, see >z/OS MVS System Messages, Vol 4 (CBD-DMO)</a>.</li></ul>
<h2 id="wq207">BCP actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes BCP migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx307"></a><a id="idx308"></a><a id="idx309"></a><a id="idx310"></a><a id="idx311"></a><a id="idx312"></a>
<h3 id="aa3iplt">Create IPL text</h3>
<p><strong>Description:</strong> IPL text is bootstrap information
required for IPL (such as the location of the nucleus library).  You
must create IPL text by running ICKDSF against the system residence
volume.<a id="idx313"></a></p>
<table id="wq208" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update and run the IPLTEXT
job to write a new copy of the IPL text. If you install z/OS with a ServerPac, an installation
dialog job is provided to perform this action. If you install z/OS with a CBPDO, instructions
to perform this action are provided in >z/OS Program Directory</a>.</p>
<div>
<div class="notelisttitle" id="wq209">Notes:</div>
<ol type="1">
<li>When the IPLTXTEXIST parameter (which was introduced by ICKDSF
R17 APAR PK16403) is specified with the REFORMAT command using the
IPLDD parameter, WTOR message ICK21836D is suppressed if IPL text
already exists.</li>
<li>ICKDSF APAR PM42057 introduced a new parameter called
REMOVEIPLTXT to the REFORMAT command that allows you to remove IPL
text from the volume. If you wish to remove IPLTEXT from a volume
that is not the IPL volume, ICKDSF APAR.</li>
</ol></div>
<p><strong>Reference information:</strong> For a sample IPLTEXT
job, see <cite>z/OS Program Directory</cite>. ServerPac provides a similar
job for accomplishing this task; see <cite>ServerPac: Installing Your Order</cite>.</p>
<h3 id="aa3sad">Reassemble the stand-alone dump program</h3>
<p><strong>Description:</strong> The stand-alone dump program
produces a dump of storage that is occupied by a system that failed
or a stand-alone dump program that failed. You must reassemble the
stand-alone dump program each release. Once the stand-alone dump program
is properly created on a DASD residence volume, it resides in the
SYS1.PAGEDUMP.Vvolser data set. <a id="idx314"></a><a id="idx315"></a><a id="idx316"></a><a id="idx317"></a></p>
<table id="wq211" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to
a specific release. See "Steps to take" for required changes to generate
a stand-alone dump program using one-stage JCL.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Reassemble the stand-alone
dump program. If you install z/OS with
a ServerPac, an installation dialog job is provided to perform this
action. If you install z/OS with
a CBPDO, instructions to perform this action are provided in >z/OS MVS Diagnosis: Tools and Service Aids</a>.</p>
<p>If you are migrating from a pre-z/OS V1R12 system where the PTF
for OA31077 is not applied, stand alone dump one-step (now called
one-stage) JCL needs to be updated to specify DDNAME of TRK0TEXT and
DSFSYSIN. Also, another job step (for DASD) to invoke ICKDSF must
be added. Sample JCL can be found in >z/OS MVS Diagnosis: Tools and Service Aids</a> and
DOC APAR OA34383.</p>
<div>
<div class="notetitle" id="wq212">Note:</div>
<div class="notebody">Starting with z/OS V1R12,
NUCLIB=(volser,unit) parameter can be specified with the AMDSADMP
macro in one-stage generation JCL. Prior to z/OS V1R12, this parameter was allowed only when
using the two-stage generation JCL.</div></div>
<p><strong>Reference information:</strong> </p>
<ul>
<li><cite>ServerPac: Installing Your Order</cite></li>
<li>>z/OS MVS Diagnosis: Tools and Service Aids</a></li></ul>
<h3 id="nucleus">Accommodate increase in nucleus size for  the z/OS V1R13 RSM Enablement Offering Web deliverable</h3>
<p><strong>Description:</strong> With the introduction of the z/OS V1R13 RSM Enablement Offering
Web deliverable, the nucleus will increase in size by approximately
380K above the 16MB line. Because of this increase, the available
private storage might affect the way your applications run on your
system.<a id="idx318"></a></p>
<table id="wq213" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R11 or z/OS V1R12
to z/OS V1R13 with z/OS V1R13 RSM Enablement Offering
Web deliverable.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13 with the z/OS V1R13
RSM Enablement Offering Web deliverable installed.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in nucleus size will affect
the private storage available to applications on your system above
the 16MB line.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None. The migration action is relevant on all
servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>The z/OS V1R13
RSM Enablement Offering Web deliverable is only available for z/OS V1R13.  z/OS V1R13 without the z/OS V1R13 RSM Enablement Offering Web deliverable, z/OS V1R12, and z/OS V1R11 are not affected by this change.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review your current available
private storage usage above the 16MB line using reports from RMF or an equivalent product. Ensure
that an increase of 380K for the nucleus above the 16 MB line will
not adversely affect your system. Adjust values accordingly.</p>
<p><strong>Reference information:</strong> See <cite></cite>and <cite></cite>.</p>
<h3 id="esqa">Accommodate increase in ESQA with the z/OS V1R13 RSM Enablement Offering Web deliverable</h3>
<p><strong>Description:</strong> With the introduction of the z/OS V1R13 RSM Enablement Offering
Web deliverable, there is an increase of 24K (6 pages) in ESQA per
CPU per LPAR. This increase in ESQA per CPU includes general purpose
CPs, zIIPs, and zAAPs. Because of this increase, the available private
storage may affect application execution on your system.</p><a id="idx319"></a><a id="idx320"></a><a id="idx321"></a>
<table id="wq214" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R11 or z/OS V1R12
to z/OS V1R13 with z/OS V1R13 RSM Enablement Offering
Web deliverable..</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13 with the z/OS V1R13
RSM Enablement Offering Web deliverable on z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in ESQA will affect the
private storage available to applications on your system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>The migration action is relevant on all servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>The z/OS V1R13
RSM Enablement Offering Web deliverable is only available for z/OS V1R13. z/OS V1R13 without the z/OS V1R13 RSM Enablement Offering Web deliverable, z/OS V1R12, and z/OS V1R11 are not affected by this change.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review your current available
private storage usage above the 16 MB line using reports from RMF or an equivalent product. Ensure
that an ESQA increase of 24K per CPU used on the LPAR will not adversely
affect your system. Adjust values  accordingly.</p>
<p><strong>Reference information:</strong> See <cite></cite>and<cite></cite>.</p>
<h3 id="pduu">Remove references to the MTFTPS utility</h3>
<p><strong>Description:</strong> Before z/OS V1R13, you might have used the problem documentation
upload utility (PDUU), packaged as MTFTPS, to send large volumes of
problem documentation, such as stand-alone dumps, to IBM support. Beginning with z/OS V1R13, the z/OS problem documentation upload utility (PDUU)
is a standard part of the base operating system with entry point name
AMAPDUPL. <a id="idx322"></a><a id="idx323"></a></p>
<table id="wq215" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you previously used the
stand-alone version of PDUU (MTFTPS).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To avoid possible conflicts,
remove the stand-alone version of the PDUU utility and begin
using the supported version:</p>
<ol type="1">
<li>Remove any prior version of MTFTPS from your system. The PDUU
utility name is AMAPDUPL <span>(in SYS1.MIGLIB)</span>, although
MTFTPS is shipped as an alias entry point to AMAPDUPL</li>
<li>Begin using the PDUU as the primary utility for sending large
volumes of product documentation to IBM Support.</li></ol>
<p><strong>Reference information:</strong> For complete details,
including JCL statements and examples, see the topic on <a href="../com.ibm.zos.r13.ieav100/pftp.htm">The z/OS Problem Documentation Upload
Utility</a> in >z/OS MVS Diagnosis: Tools and Service Aids</a>.</p>
<h3 id="oa35357">Change value for ARM restart processing</h3>
<p><strong>Description:</strong> Before performing cross-system
restart, automatic restart management (ARM) waits for member cleanup
for the terminated system to complete. ARM proceeds with cross-system
restart if cleanup takes longer than a certain amount of time. Before z/OS V1R13, this time was two minutes.
Support for a new parameter, CLEANUP_TIMEOUT, is available with the
PTFs for APAR OA35357 applied to z/OS V1R13, z/OS V1R12, z/OS V1R11, and z/OS V1R10.
The default for this new parameter is five minutes. That is, ARM will
wait five minutes for member cleanup for a terminated system to complete
before performing cross-system restart for an element. ARM performs
cross-system restart when member cleanup completes or when the CLEANUP_TIMEOUT
expires, whichever comes first.</p>
<p>Starting with z/OS V1R13,
the CLEANUP_TIMEOUT parameter can be used to indicate that ARM is
to wait additional time for member cleanup for a terminated system
to complete. To get the two minute timeout behavior that existed before
the default change, CLEANUP_TIMEOUT(120)  must be added to the ARM
policy. If you do not specify CLEANUP_TIMEOUT(120), the system issues
the following message to the system log to record when CLEANUP_TIMEOUT
has an effect on cross-system restart processing:</p>
<pre class="xmp"><code>IXC815I MEMBER CLEANUP FOR SYSTEM <var class="pv">sysname1</var> NUMBER <var class="pv">sysnum1</var> INCOMPLETE</code></pre>
<p>If the member cleanup does not occur within the time specified
by the CLEANUP_TIMEOUT parameter, automatic restart management will
proceed with processing the element for cross-system restart, and,
if CLEANUP_TIMEOUT(120) is not being used, the system will issue IXC815I
to the system log to record the time out. </p>
<pre class="xmp"><code>IXC815I MEMBER CLEANUP FOR SYSTEM <var class="pv">sysname1</var> NUMBER <var class="pv">sysnum1</var> INCOMPLETE. 
<br />
JOBNAME <var class="pv">jobname</var>, ELEMENT <var class="pv">elementname</var> 
<br />
RESTART DELAY TIMED OUT AFTER <var class="pv">dec</var> SECOND(S).</code></pre>
<p>When a CLEANUP_TIMEOUT value greater than 120 is specified
(or defaulted to), and additional delay is introduced to wait for
member cleanup processing to complete, message IXC815I is issued to
the system log to record the delay in performing restart processing. </p>
<pre class="xmp"><code>IXC815I MEMBER CLEANUP FOR SYSTEM <var class="pv">sysname1</var> NUMBER <var class="pv">sysnum1</var> INCOMPLETE. 
<br />
JOBNAME <var class="pv">jobname</var>, ELEMENT <var class="pv">elementname</var> 
<br />
RESTART IS DELAYED FOR UP TO <var class="pv">dec</var> SECOND(S). 
<br />
RESTART IS FOR THE FAILURE OF SYSTEM <var class="pv">sysname2</var> NUMBER <var class="pv">sysnum2</var>.</code></pre><p class="indatacontent"> .</p>
<p>        <a id="idx324"></a><a id="idx325"></a></p>
<table id="wq217" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13,
and rolled back to z/OS V1R12, z/OS V1R11, and z/OS V1R10 by APAR OA35357.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11 without the
PTFs for OA35357 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have the PTF for APAR OA35357 applied
and a five-minute timeout for member cleanup is not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>The new five minute default, or any use of the
CLEANUP_TIMEOUT parameter other than CLEANUP_TIMEOUT(120), is not
fully effective until all systems in the sysplex have support for
the CLEANUP_TIMEOUT parameter. APAR OA35357 provides support for the
CLEANUP_TIMEOUT parameter.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you prefer to use the two
minute value for ARM restart processing, do the following:</p>
<ol type="1">
<li>Use the z/OS V1R13 version
of IXCMIAPU to define an ARM policy with CLEANUP_TIMEOUT(120).</li>
<li>Use the SETXCF START command to start the new or updated policy.</li></ol>
<p><strong>Reference information:</strong> For details, see the
topic &quot;Automatic restart management parameters for administrative
data utility&quot; in the chapter &quot;Administrative data utility&quot;
in >z/OS MVS Setting Up a Sysplex</a>.</p>
<h3 id="dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</h3><a id="idx326"></a><a id="idx327"></a>
<p><strong>Description:</strong> Before z/OS V1R13, when the following <span class="pk">D XCF</span> console
commands were issued, the resulting messages contained output information
from the command depending on the options specified: </p>
<ul>
<li><span class="pk">D XCF</span>
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <var class="pv">sysplex-name</var>: <var class="pv">sysname sysname</var>
     <var class="pv">sysname</var> <var class="pv">sysname</var></code></pre></li>
<li><span class="pk">D XCF,SYSPLEX</span>
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <var class="pv">sysplex-name</var>: <var class="pv">sysname sysname</var>
     <var class="pv">sysname</var> <var class="pv">sysname</var></code></pre></li>
<li><span class="pk">D XCF SYSPLEX,ALL</span>
<pre class="xmp"><code>IXC335I   hh.mm.ss  DISPLAY XCF <var class="pv">text</var></code></pre></li></ul>
<p>Starting with z/OS V1R13,
the output message for a <span class="pk">D XCF,SYSPLEX</span> command is changed
to IXC336I, which provides more basic information about a system.
In addition, a new output message, IXC337I, is issued for a <span class="pk">D
XCF,SYSPLEX</span> command when a system name or ALL is specified. Detailed
sysplex and system information was added and reformatted in the new
message. These changes can affect your message automation programs.</p>
<ul>
<li><span class="pk">D XCF</span>
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <var class="pv">sysplex-name</var>: <var class="pv">sysname sysname</var>
     <var class="pv">sysname</var> <var class="pv">sysname</var></code></pre></li>
<li><span class="pk">D XCF,SYSPLEX</span>
<pre class="xmp"><code>IXC336I hh.mm.ss DISPLAY XCF text
SYSTEM  TYPE  SERIAL  LPAR  STATUS TIME  SYSTEM STATUS
<var class="pv">sysname</var> <var class="pv">type</var>  <var class="pv">serial</var>  <var class="pv">lpar</var>    <var class="pv">m/dd/yyyy</var>         <var class="pv">status</var>

SYSTEM STATUS DETECTION PARTITIONING PROTOCOL CONNECTION EXCEPTIONS: <var class="pv">local_limit</var> 
SYSTEM DIAG INFO: <var class="pv">cpiiservice faileddatetime retcode</var>
SYSTEM ABEND CODE: <var class="pv">abendcode</var> ABEND REASON CODE: <var class="pv">abendrsncode</var>
TIME OF FAILURE: <var class="pv">abenddatetime</var></code></pre></li>
<li><span class="pk">D XCF,SYSPLEX,ALL</span> | <var class="pv">system name</var>
<pre class="xmp"><code>IXC337I hh.mm.ss DISPLAY XCF
SYSPLEX <var class="pv">sysplex-name</var> MODE: <var class="pv">plex_mode</var>
SYSTEM <var class="pv">system-name</var> STATUS: <var class="pv">system-status
                                         system-status</var>
TIMING: <var class="pv">system-timing</var>
STATUS TIME: <var class="pv">activetime</var>
JOIN TIME: <var class="pv">activetime</var>
SYSTEM NUMBER: <var class="pv">system-number</var></code></pre></li></ul>
<table id="wq219" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle message IXC335I and IXC334.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Modify automation that references
output from <span class="pk">D XCF,SYSPLEX</span>, <span class="pk">D XCF,SYSPLEX,ALL</span>, and <span class="pk">D
XCF,SYSPLEX,</span><var class="pv">systemname</var> commands. Message IXC337I replaces
IXC335I. IXC335I is no longer issued.</p>
<p><strong>Reference information:</strong> For details about
the message output for IXC334I, IXC336I, and IXC337I, see >z/OS MVS System Messages, Vol 10 (IXC-IZP)</a>.</p>
<h3 id="llaauto">Update LLA for automation</h3>
<p><strong>Description:</strong> Before z/OS V1R13, if you started library lookaside (LLA)
using a CSVLLA<var class="pv">xx</var> parmlib member, and then stopped and restarted
LLA without using a parmlib member, LLA honored the "no parmlib member"
state and managed only the data sets in the LNKLST concatenation.
Beginning with z/OS V1R13,
the same scenario results in using the CSVLLA<var class="pv">xx</var> parmlib member
with which LLA previously started. To get back to the "no parmlib
member" state, you must specify <span class="pk">LLA=NONE</span> when starting LLA.</p>
<p></p><a id="idx328"></a><a id="idx329"></a><a id="idx330"></a><a id="idx331"></a>
<table id="wq220" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation or operator procedures
that restart LLA and you want LLA to restart with no parmlib member
even when you previously started LLA with a parmlib member.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you have automation in
place to restart LLA and you want automation to restart without a
parmlib member even when you had started LLA with a parmlib member,
you must change it to use the <samp class="xph">LLA=NONE</samp> parameter.</p>
<div>
<div class="notetitle" id="wq221">Note:</div>
<div class="notebody">If you issue the F LLA,UPDATE=xx command
in between the start and stop, the update is not made by the restarted
LLA, which is brought up without specifying LLA=xx.</div></div>
<p><strong>Reference information:</strong> See the topic on <a href="../com.ibm.zos.r13.ieae200/csvlla.htm">CSVLLAxx (library lookaside
(LLA) list)</a> in >z/OS MVS Initialization and Tuning Reference</a></p>
<h3 id="operloge">Accommodate OPERLOG EMCS console name change</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13 (and z/OS V1R12, z/OS V1R11,
and z/OS V1R10 with the PTF
for APAR OA31913 applied), the OPERLOG EMCS console name *OPLOG<var class="pv">yy</var> is
generated using the two character System Clone value (&amp;SYSCLONE).
The default &amp;SYSCLONE value is obtained from the System Name (&amp;SYSNAME)
(for example, System Name = SYSTEM1 / System Clone = M1 ). This naming
convention is similar to the SYSLOG EMCS console (*SYSLG<var class="pv">yy</var>).<a id="idx332"></a></p>
<table id="wq222" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(z/OS V1R12, z/OS V1R11, z/OS V1R10,
and z/OS V1R9 by APAR OA31913).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11, both without
the PTF for APAR OA31913 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you depend on the OPERLOG EMCS console
name.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> The change of OPERLOG EMCS
console name spans all configurations (MULTISYSTEM, XCFLOCAL, MONOPLEX,
in GRS RING or STAR mode). If you depend on the name of OPERLOG EMCS
console in your own procedure, it must be adjusted to reflect this
change. For example, the following will display the OPERLOG EMCS console
name:</p>
<pre class="xmp"><code>D C,KEY=OPERLOG (message IEE892I)
D EMCS (message IEE129I)
D EMCS,CN=*OPLOG* (message IEE129I)</code></pre>
<div>
<div class="notetitle" id="wq223">Note:</div>
<div class="notebody">With the
PTF for APAR OA30757 applied to z/OS V1R11
or z/OS V1R10, and in z/OS V1R12, this change was already
in effect.</div></div>
<p><strong>Reference information:</strong> For more information
about the OPERLOG EMCS console, see >z/OS MVS Planning: Operations</a>.</p>
<h3 id="conparm">Adjust CON= system parameter to accommodate default change</h3>
<p><strong>Description:</strong> Before z/OS V1R13, the default console
operating mode was SHARED. Beginning with z/OS V1R13, the default console operating mode is
changing from SHARED mode to DISTRIBUTED mode. A release later than z/OS V2.1 is planned to be the
last release in which the consoles component will support shared mode.
SHARED mode will be removed in that future release. DISTRIBUTED mode
is now the preferred mode of operations.</p><a id="idx333"></a><a id="idx334"></a><a id="idx335"></a>
<table id="wq224" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if there is no specification on the CON=
system parameter and SHARED mode is required.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Impacts could be experienced falling back to
shared, but only after taking advantage of some of the functionality
offered in distributed. For more information, see "Operation modes
of console support" in >z/OS MVS Planning: Operations</a>.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check ZOSMIGV1R13_CNZ_CONS_OPER_MODE<span>, available with APAR OA32930,</span> to determine if your
installation has explicitly identified your console service operating
mode.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Examine the system parameters
used to IPL the system or sysplex. The initial mode is specified on
the CON= system parameter. <span>Use the <span class="pk">D OPDATA,MODE</span> to
find the current mode, which is displayed in message CNZ9006I.</span></p>
<ul>
<li>If DISTRIBUTED is specified, no action is required.</li>
<li>If SHARED is specified, an action is not currently required, but
DISTRIBUTED mode will become a required action in the future.</li>
<li>If there is no specification on the CON= system parameter, DISTRIBUTED
mode is now the default.</li>
<li>If there is no specification on the CON= system parameter and
SHARED mode is required, you have to explicitly request the SHARED
mode on the CON= system parameter. This allows the system or systems
to continue functioning in the same manner as they do today. <span>If
you are in a in a MULTISYSTEM sysplex environment, use the SETCON
MODE=SHARED command to request SHARED mode.</span></li></ul><p class="indatacontent"> <span><strong>Tip:</strong> When you activate the
OPERCMDS FACILITY class, you must have the CONTROL access authority
to the profile when issuing the SETCON MODE command.</span></p>
<p><strong>Reference information:</strong> For more information,
see:</p>
<ul>
<li>DOC APAR OA34738.</li>
<li> >z/OS MVS Initialization and Tuning Reference</a>.</li>
<li>>z/OS MVS Planning: Operations</a>.</li></ul>
<h3 id="hyperz196">Accommodate HiperDispatch default of YES on IBM zEnterprise zEC12 and IBM zEnterprise (z196 and z114)</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R13 when running on a z196 or z114 server,
the IEAOPT<var class="pv">xx</var> keyword HIPERDISPATCH will default to YES. If
HIPERDISPATCH=NO is specified, the specification will be honored as
it was on previous z/OS releases.<a id="idx336"></a><a id="idx337"></a></p>
<table id="wq225" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but it is recommended. You should be aware
of changes in how system resources are being managed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>IBM zEnterprise zEC12, z196,
or z114.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use IBM z/OS Health Checker check SUP_HiperDispatch
to determine whether the expected HiperDispatch check parameter state,
HIPERDISPATCH YES | NO, matches the actual HiperDispatch state of
the system.
<p>Beginning with z196 and z114 machines on z/OS V1R13, anyone making the SUP_HiperDispatch
health check succeed by specifying a parameter of HIPERDISPATCH(NO)
for a z/OS image running in
HIPERDISPATCH=NO will need to specify the machine types(s) where HiperDispatch(NO)
is acceptable using the MachTypes parameter; for example, MachTypes(2817).</p>
<p>If
the HiperDispatch(NO) parameter is provided to the SUP_HiperDispatch
health check, the machine is a z196 or a z114, and the current machine
type does not appear in the MachTypes list, the check will expect
a HiperDispatch state of HIPERDISPATCH(YES).</p></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<p>Examine one or more of the IEAOPT<var class="pv">xx</var> members
used for each z/OS V1R13 image
that will be IPLed on a zEC12, z196, or a z114. Then find the HIPERDISPATCH
keyword and take one of the following actions:</p>
<ul>
<li>For HiperDispatch=YES, no action is required.</li>
<li>When the HiperDispatch keyword is omitted, note that the image
will take the default of HiperDispatch=YES and IPL with HiperDispatch
enabled. Decide if you wish to accept that HiperDispatch will be enabled
by default by reviewing the subsequent steps, and the &quot;HiperDispatch=YES
considerations&quot; section.</li>
<li>For HiperDispatch=NO, investigate why that image was running in
HiperDispatch=NO and choose one of the following:
<ul>
<li>Define a plan to migrate that image to HiperDispatch=YES. See
the &quot;HiperDispatch=YES considerations&quot; section for further
information.</li>
<li>Continue to run the image with HiperDispatch=NO (IBM does not recommend this option for LPARs where
the LPAR weight guarantees a share of two or more physical processors
without a compelling reason for running HiperDispatch=NO).
<p>To get
the SUP_HiperDispatch health check to succeed, add the machine type
to the MachTypes parameter and verify that the HIPERDISPATCH parameter
is NO.</p></li></ul></li></ul>
<p><strong>Tip</strong>: You can issue the RMF Monitor-II OPT command introduced
in z/OS V1R11 to get the current
IEAOPTxx parmlib setting.</p>
<p><strong>HiperDispatch=YES considerations</strong>:</p>
<ul>
<li>Before enabling HiperDispatch review the WLM policy and make appropriate
changes as needed that are described in the &quot;WLM Policy Considerations&quot;
in the &quot;Planning Considerations For HiperDispatch Mode&quot; white
paper at http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229.</li>
<li>Verify that the LPAR profiles of the partitions in which the system
may be IPLed allow for "Global Performance Data Control". See the <em>Processor Resource/Systems Manager&trade; Planning Guide</em> for
a description of this capability. If this capability is not allowed,
WLM will be unable to understand capacity that is  used by other LPARs
and will use all logical processors. Using all logical processors
will result in suboptimal use of cache, reducing the capacity of the
partition when more logical processors are defined compared to the
share of the partition. This can also result in the "short CP" effect
where a logical processor may have a unit of work dispatched while
removed from a physical processor for significant intervals. This
can lead to response time problems.</li></ul>
<p><strong>Reference information:</strong></p>
<ul>
<li><em>&quot;Planning Considerations for HiperDispatch
Mode&quot; white paper</em>  at IBM Techdocs <a href="http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229">http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229</a>.</li>
<li><em>Processor Resource/Systems Manager Planning Guide</em></li>
<li>>z/OS MVS Initialization and Tuning Reference</a></li>
<li>>z/OS MVS Planning: Workload Management</a></li>
<li>>IBM Health Checker for z/OS: User&rsquo;s Guide</a></li></ul>
<h3 id="commndxx">Start Runtime Diagnostics at system initialization</h3><a id="idx338"></a><a id="idx339"></a>
<p><strong>Description:</strong> Before z/OS V1R13, Runtime Diagnostics ran as a as a started
task under the master subsystem and had to be started each time you
wanted an analysis. It was started, did its analysis, then ended.
Beginning with z/OS V1R13,
you can start Runtime Diagnostics to run as an address space under
the master subsystem. After you start the Runtime Diagnostics address
space (HZR), it remains running until stopped using the STOP command.
Use the <samp class="xph">MODIFY HZR,ANALYZE</samp> command to generate a Runtime
Diagnostics analysis and report.<a id="idx340"></a><a id="idx341"></a></p>
<table id="wq226" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to use Runtime Diagnostics.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To start the Runtime Diagnostics
address space (HZR) on z/OS V1R13:
 </p>
<ol type="1">
<li>Ensure the hzrproc (HZR) points to PGM=HZRINIT, not PGM=HZRIMAIN
as in z/OS V1R12. The hzrproc
(HZR) ships in the SYS1.PROCLIB data set.</li>
<li>If you want to start Runtime Diagnostics address space (HZR) during
system initialization, specify <samp class="xph">COM='S HZR,SUB=MSTR'</samp> in
the COMMND<var class="pv">xx</var> parmlib member. Otherwise, the HZR address space
must be started manually: <samp class="xph">S HZR,SUB=MSTR</samp></li>
<li>After the Runtime Diagnostics address space (HZR) is started,
use the <samp class="xph">MODIFY HZR,ANALYZE</samp> command to generate Runtime
Diagnostics&rsquo; reports.</li></ol>
<p><strong>Reference information:</strong> For complete details
about using Runtime Diagnostics, see the topic on <a href="../com.ibm.zos.r13.e0zk100/rtdin.htm">Runtime Diagnostics overview</a> in >z/OS Problem Management</a>.</p>
<h3 id="sysevent">Ensure all modules of an application are compiled with the
same version of the IRARASD macro</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, the IRARASD macro (field RQFASDWA) defines
a 512-byte (changed from 338-byte) work area for SYSEVENT
REQFASD. When you recompile a module that includes the IRARASD macro,
you must also recompile all other modules that include the IRARASD
macro and belong to the same application.   <a id="idx342"></a><a id="idx343"></a></p>
<p>It is only necessary to ensure that all modules of an application
use the same version of the IRARASD macro; it is not necessary to
recompile all modules with the z/OS V1R12
version of the IRARASD macro.</p>
<table id="wq228" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid incompatible work area sizes between
program and declaration when declaration of the work area is done
outside the program (DSECT).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure all modules of an application
are compiled with the same version of the IRARASD macro.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>See APAR OA33666.</li>
<li>See macro IRARASD in SYS1.MACLIB</li></ul>
<h3 id="oa34731">Issue commands from the system console regardless of problem
determination mode</h3><a id="idx344"></a><a id="idx345"></a>
<p><strong>Description:</strong> Before z/OS V1R12, the system console could not issue any
commands (except <span class="pk">REPLY</span> and <span class="pk">VARY CN(*),ACTIVATE</span>)
unless it was placed in problem determination (PD) mode through the <span class="pk">VARY
CN(*),ACTIVATE</span> command. Starting with z/OS V1R12, processing changed so that commands
could always be entered at the system console regardless of problem
determination mode. With APAR OA34731, commands can only be entered
at the system console if the <span class="pk">CONSOL</span><em>xx</em> keyword
ALLOWCMD(Y) is specified on the system console definition.</p><a id="idx346"></a>
<table id="wq229" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
with APAR OA34731 and z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td> z/OS V1R12
without the PTF for OA34731 installed and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to immediately enter commands
from the system console during critical situations.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>The parmlib statement <span class="pk">ALLOWCMD</span> in <span class="pk">CONSOL</span><span class="mv">xx</span> 
is not tolerated on systems that do not have the PTF for APAR OA34731
installed.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use CHECK(CNZ_SYSCONS_ALLOWCMD) to compare the <span class="pk">ALLOWCMD</span> setting
for the system console with the setting specified on the check.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Add <span class="pk">ALLOWCMD(Y)</span> to
the system console definition in the <span class="pk">CONSOL</span><em>xx</em> member
of PARMLIB if you wish to allow commands to be issued from the system
console regardless of problem determination mode. For z/OS V1R12 you must apply APAR
OA34731 in order to use the ALLOWCMD option. Note that commands can
be issued from the system console by default regardless of problem
determination mode.</p>
<p><strong>Reference information:</strong></p>
<ul>
<li>PTF HOLD information for APAR OA34731.</li></ul>
<h3 id="ief37smf">Update automation that handles messages IEF374I and IEF376I</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, message IEF374I is replaced by message
IEF032I, and message IEF376I is replaced by message IEF033I. If you
use automation programs to handle messages, or you have operator or
other procedures that deal with messages, you should update the programs
or procedures appropriately.</p>
<p>Sample output of new messages for z/OS V1R12:</p>
<pre class="xmp"><code>IEF142I BEANSZZ STEP1 - STEP WAS EXECUTED - COND CODE 0000 
IEF373I STEP/STEP1 /START 2010272.2014 
IEF032I STEP/STEP1 /STOP 2010272.2014 
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC 
VIRT: 4K SYS: 232K EXT: 0K SYS: 11936K 
IEF375I JOB/BEANSZZ /START 2010272.2014 
IEF033I JOB/BEANSZZ /STOP 2010272.2014 
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC </code></pre><a id="idx347"></a>
<table id="wq230" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle messages IEF374I and IEF376I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>APAR PM23467 is needed for the Tivoli&reg; Workload Scheduler (TWS)
product.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Modify automated actions for IEF374I so they now work with message
IEF032I.</li>
<li>Modify automated actions for IEF376I so they now work with message
IEF033I.</li></ul>
<p><strong>Reference information:</strong> For details about
messages IEF032I and IEF033I, see >z/OS MVS System Messages, Vol 8 (IEF-IGD)</a>.</p>
<h3 id="ctigrsd">Use the new 16M default buffer size for trace options with
the CTIGRSxx member</h3>
<p><strong>Description:</strong> Before z/OS V1R12, the default buffer
value (BUFSIZE) for the trace option with the GRS component in the
IBM-supplied CTIGRS00 parmlib member was 128K, the maximum value was
16MB, and the buffer was in GRS below the bar private storage. Starting
with z/OS V1R12, the default
size in CTIGRS00 is increased to 16MB, the maximum is 2047MB, and
the buffer is in GRS above the bar private storage in its own memory
object. If you specify your own CTIGRS<var class="pv">xx</var> member on the CTRACE
option in GRSCNF<var class="pv">xx</var> parmlib member, change the BUFSIZE in
CTIGRS<var class="pv">xx</var> to 16MB. Until OA39771 has been applied, supply
a buffer size for GRS or the default will not be used correctly,<a id="idx348"></a><a id="idx349"></a></p>
<table id="wq231" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you modified any IBM-supplied procedures.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Change the trace option BUFSIZE
in CTIGRS<var class="pv">xx</var> parmlib member to 16M or make the new default
value (16M) active.</p>
<p><strong>Reference information:</strong> For more information,
see &quot;Trace buffer values&quot; >z/OS MVS Diagnosis: Tools and Service Aids</a> and >z/OS MVS JCL Reference</a>.</p><a id="idx350"></a><a id="idx351"></a><a id="idx352"></a><a id="idx353"></a>
<h3 id="ifasmf1">Specify valid user exits for the IFASMFDL and IFASMFDP programs</h3>
<p><strong>Description:</strong> When you run the SMF log stream
dump program (IFASMFDL) or the SMF data set dump program (IFASMFDP),
the name of an installation-written exit routine that is given control
at the indicated times can be specified by the USER<var class="pv">x</var> (<var class="pv">x</var>=1,
2, or 3) parameter.</p>
<p>Beginning with z/OS V1R12
(and z/OS V1R11 with the PTFs
for APAR OA29894 applied), to allow user exits to be called by the
SMF dump programs, the exits must now be pre-defined to the
system using the new keywords shipped in the SMFPRM<var class="pv">xx</var> parmlib
member. The SMFDLEXIT keyword allows exits to be specified for the
IFASMFDL program, and the SMFDPEXIT keyword allows exits to be specified
for the IFASMFDP program.</p>
<p>Both keywords have the same suboptions, USER1, USER2 and USER3.
The suboptions allow multiple exits to be specified for each user
exit point in the respective dump program. The syntax follows.</p>
<pre class="xmp"><code>SMFDLEXIT(  USER1( exit1, exit2, ... ) | NOUSER1  ,
               USER2( exit1, exit2, ... ) | NOUSER2  ,
               USER3( exit1, exit2, ... ) | NOUSER3  )
SMFDPEXIT(  USER1( exit1, exit2, ... ) | NOUSER1  ,
               USER2( exit1, exit2, ... ) | NOUSER2  ,
               USER3( exit1, exit2, ... ) | NOUSER3  )</code></pre><a id="idx354"></a><a id="idx355"></a>
<div>
<div class="notetitle" id="wq232">Note:</div>
<div class="notebody">In z/OS V1R13,
or with the PTF for SMF APAR OA33696 applied to z/OS V1R12 or z/OS V1R11,
IFASMFDP can once again run in a non-APF authorized environment when
using the DUMP option. Also, when IFASMFDP is executed in an unauthorized
environment, the exits specified with USER1, USER2 and USER3 will
not be verified against what is in the SMFPRM<var class="pv">xx</var> parmlib member.</div></div>
<table id="wq233" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12. z/OS V1R11, z/OS V1R10, and z/OS V1R9
with APAR OA29894.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without the PTF for APAR OA29894 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the user exit routines.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>You must apply the PTF for APAR OA29894 if you
share the SMFPRM<var class="pv">xx</var> parmlib member, with the keyword SMFDLEXIT
or SMFDPEXIT specified, on multiple systems.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Register an exit specified for IFASMFDL or IFASMFDP using the
USER1, USER2 or USER3 parameters through the SMFPRM<var class="pv">xx</var> parmlib
member. If you fail to do this, you will receive the following error
message, and IFASMFDL or IFASMFDP will stop the processing:
<pre class="xmp"><code>IFA840I USER EXIT <var class="pv">xxxxxxxx</var> NOT REGISTERED WITH SYSTEM</code></pre></li>
<li>View the D SMF,O command output to determine if the exits are
successfully registered.</li></ul>
<p></p>
<div>
<div class="notetitle" id="wq234">Note:</div>
<div class="notebody"> You do not need to explicitly define the exits
used by the operation of RACF SMF
unload utility; they are registered by default.</div></div>
<pre class="xmp"><code>Default: SMFDLEXIT(USER2(IRRADU00),USER3(IRRADU86))
         SMFDPEXIT(USER2(IRRADU00),USER3(IRRADU86))</code></pre>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about the SMFPRM<var class="pv">xx</var> parmlib member, see >z/OS MVS Initialization and Tuning Reference</a>.</li>
<li>For details about SMF dump programs, see >z/OS MVS System Management Facilities (SMF)</a>.</li></ul>
<h3 id="ifasmf2">Make IFASMFDL and IFASMFDP run in an authorized environment</h3>
<p><strong>Description:</strong> When you run the SMF log stream
dump program (IFASMFDL) or SMF data set dump program (IFASMFDP), the
DUMP function is permitted even in an unauthorized environment. (Note:
The CLEAR function of the SMF data set dump program requires APF authorization.
No such function exists for the SMF log stream dump program.</p>
<p>Beginning with z/OS V1R12
(and z/OS V1R11 with the PTFs
for APAR OA29894 applied), the IFASMFDL and IFASMFDP programs are
required to run in an authorized environment. Otherwise, the programs
will lose authorization and you will get an S338 followed by a S330
abend, especially if the programs are being executed under TSO/E.</p>
<div>
<div class="notetitle" id="wq235">Note:</div>
<div class="notebody">In z/OS V1R13,
or with the PTF for SMF APAR OA33696 applied to z/OS V1R12 or z/OS V1R11,
IFASMFDP can once again run in a non-APF authorized environment when
using the DUMP option.</div></div>
<p><a id="idx356"></a><a id="idx357"></a></p>
<table id="wq236" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12. z/OS V1R11, z/OS V1R10, and z/OS V1R9
with APAR OA29894.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without the PTF for APAR OA29894 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not invoke the SMF dump program
as a jobstep task.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> </p>
<ul>
<li>If you run the SMF dump program using JCL, the APF-authorization
assigned to it is preserved, and no action is required.</li>
<li>For the TSO/E environment, you need to add IFASMFDL and IFASMFDP
to the AUTHPGM section of the IKJTSO<var class="pv">xx</var> parmlib member when
the programs are being invoked using a TSO/E CALL command.</li>
<li>If LINKMVS or ATTCHMVS is used in a REXX program to invoke IFASMFDL
or IFASMFDP, change the invocations of IFASMFDL and IFASMFDP using
LINKMVS or ATTCHMVS to use the TSO/E CALL command. In addition, add
the IFASMFDL and IFASMFDP program to the AUTHPGM section of the IKJTSO<var class="pv">xx</var> parmlib
member.</li>
<li>If calling IFASMFDL or IFASMFDP from another program, that program
must be authorized.</li></ul><p class="indatacontent"> </p>
<div>
<div class="notetitle" id="wq237">Note:</div>
<div class="notebody">A ++HOLD(ACT) is being shipped with the PTFs
for APAR OA32258 to notify that IFASMFDL and IFASMFDP need to be executed
in an authorized environment.</div></div>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about IKJTSO<var class="pv">xx</var> parmlib member, see >z/OS MVS Initialization and Tuning Reference</a>.</li>
<li>For details about SMF dump programs, see >z/OS MVS System Management Facilities (SMF)</a>.</li></ul>
<h3 id="pfaparm">Provide the <var class="pv">migrate</var> or <var class="pv">new</var> parameter
when running the PFA install script</h3>
<p><strong>Description:</strong> Before z/OS V1R12, when installing Predictive Failure Analysis
(PFA) it was not necessary for you to specify how to handle the existing
data in the check directories. Beginning with z/OS V1R12, you must append a parameter, <var class="pv">migrate</var> or <var class="pv">new</var>,
on the installation script to specify if the PFA check directories
retain data from the prior release. If you do not append the <var class="pv">migrate</var> or <var class="pv">new</var> parameter,
the AIRSHREP.sh script fails.</p><a id="idx358"></a><a id="idx359"></a><a id="idx360"></a>
<table id="wq238" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using PFA.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Refer to >z/OS Problem Management</a> for
considerations and actions required for Predictive Failure Analysis
(PFA) when falling back to z/OS V1R12
or z/OS V1R11 from z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Provide the <var class="pv">migrate</var> or <var class="pv">new</var> parameter
when running the PFA install script, AIRSHREP.sh, or when using the
sample JCL for batch provided in SYS1.SAMPLIB. </p>
<ul>
<li><var class="pv">migrate</var>: Use the <var class="pv">migrate</var> parameter to preserve
PFA history data from the prior release. The <var class="pv">migrate</var> option
is recommended for all installations that previously used PFA. When
you specify the <var class="pv">migrate</var> parameter, the install script preserves
data from the prior release and creates new directory structures for
checks not previously installed on your system.</li>
<li><var class="pv">new</var>: Use the <var class="pv">new</var> parameter if you are installing
PFA for the first time or if you want to delete everything from prior
releases and start PFA with new directories. When you specify the <var class="pv">new</var> parameter,
the install script deletes the existing check directories and creates
a new directory structure for all the checks.</li></ul>
<p>For example, to run the install script from your home directory:</p>
<ol type="1">
<li>On the OMVS command line, go to the home directory for the PFA
user: <samp class="xph">cd var/pfa</samp></li>
<li>Run the install script appending the migrate parameter:  <samp class="xph">/usr/lpp/bcp/AIRSHREP.sh
migrate</samp></li></ol>
<p><strong>Reference information:</strong> For complete details,
see the topic on <a href="../com.ibm.zos.r13.e0zk100/iplpfa.htm">Steps for installing PFA</a> in >z/OS Problem Management</a>.</p>
<h3 id="lccapcca">Change default locations for LCCA or PCCA control blocks to
retain 24-bit virtual storage location</h3>
<p><strong>Description:</strong> In parmlib member DIAG<var class="pv">xx</var>,
you can specify the virtual location of the LCCA control block (mapped
by the IHALCCA macro) or the location of the PCCA control block (mapped
by the IHAPCCA macro) to be used when a CPU is brought online.
Before z/OS V1R12, if the IHALCCA
or IHAPCCA structures specified on the CBLOC VIRTUAL24 or VIRTUAL31
keyword of DIAG<var class="pv">xx</var> did not specify either the 24-bit
(VIRTUAL24) or 31-bit (VIRTUAL31) location, the default location
for the LCCA or PCCA was in 24-bit virtual storage.</p>
<p>Beginning with z/OS V1R12,
the default location for the LCCA and PCCA is now in 31-bit
virtual storage if you do not specify VIRTUAL24 or VIRTUAL31 for the
structures IHALCCA and IHAPCCA. If only one standard processor
is online during the IPL, the LCCA and PCCA of the IPL CPU will be
in 24-bit storage regardless of the specification. If there is more
than one processor, and DIAGxx permits it, you'll have the LCCA and
PCCA in 31-bit storage. <a id="idx361"></a><a id="idx362"></a><a id="idx363"></a><a id="idx364"></a></p>
<table id="wq240" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to keep the 24-bit virtual
storage location for IHALCCA or IHAPCCA.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> The following z/OS V1R12
migration checks, (available with APAR OA32015 on z/OS V1R11), determine if your current settings
match RMODE 31 for the LCCA or PCCA control blocks: 
<div class="lines">CHECK(IBMSUP,ZOSMIGV1R12_SUP<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_LCCA_ABOVE_16M) <br />
CHECK(IBMRCF,ZOSMIGV1R12_RCF<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_PCCA_ABOVE_16M)<br />
</div>
<p>As is the convention, these checks
are shipped inactive and are to be activated when exploring migration
actions.</p></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you want to retain the
24-bit virtual storage location for IHALCCA or IHAPCCA, specify VIRTUAL24
on the CBLOC keyword in DIAG<var class="pv">xx</var> parmlib member:</p>
<pre class="xmp"><code>VIRTUAL24(IHALCCA)
VIRTUAL24(IHAPCCA)</code></pre>
<p><strong>Reference information:</strong> For information, see >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h3 id="cunidhc">Remove reference to Unicode Services pre-built image
CUNIDHC2</h3>
<p><strong>Description:</strong> Starting in z/OS V1R7, Unicode Services provided support to
dynamically load tables into storage when a Unicode service request
is made and the table is not already in storage. This enhancement
is colloquially known as &quot;Unicode On Demand.&quot; If the appropriate
table needed to satisfy the service request is not in storage, Unicode
Services will load the table dynamically without disrupting the caller's
request. All tables needed for character conversion, case conversion,
normalization, and collation services are now loaded automatically
into storage when they are required and not already present. These
tables are added to other tables already in storage.</p>
<p>Starting in z/OS V1R12,
the pre-built image CUNIDHC2  has been eliminated. This pre-built
image contained all the conversion tables supported by DB2 and would be loaded into storage
when you had an empty Unicode environment (no UNI=<var class="pv">xx</var> in the
IEASYS<var class="pv">xx</var> member) and the first requestor of a Unicode conversion
service would be DB2. Given
that most customers would use only a handful of these tables and given
that Unicode Service has the capability to dynamically load tables
into storage, the need for pre-built image has become obsolete. Unicode
Services will no longer ship the pre-built image SYS1.SCUNIMG(CUNIDHC2)
and will no longer automatically load the pre-built image.  We recommend
that you use the Unicode On Demand capability to load all tables. <a id="idx365"></a></p>
<table id="wq241" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the SYS1.SCUNIMG is in the LNKLST specification.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Remove SYS1.SCUNIMG from the LNKLST specification.</li>
<li>Remove SYS1.SCUNIMG from the APF authorization list. Note that
if your installation is running with the entire LNKLST as APF authorized
(LNKAUTH=LNKLST), you do not need to take any additional action. If
your installation is not running with the LNKLST as APF authorized
(LNKAUTH=APFTAB), you need to explicitly remove the APF authorization
for this data set.</li>
<li>Remove the catalog entry for SYS1.SCUNIMG.</li>
<li>Remove the following DDDEF entries: 
<div class="lines">&nbsp;&nbsp;&nbsp;<span class="bold-underlined">Name</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="bold-underlined">Data Set Name</span><br />
&nbsp;&nbsp;&nbsp;ACUNIMG&nbsp;&nbsp;&nbsp;SYS1.ACUNIMG <br />
&nbsp;&nbsp;&nbsp;SCUNIMG&nbsp;&nbsp;&nbsp;&nbsp;SYS1.SCUNIMG <br />
</div></li></ul>
<div>
<div class="notetitle" id="wq242">Note:</div>
<div class="notebody">If you want to create and load an image with
the same conversion tables as the eliminated pre-built image, do the
following: 
<ol type="1">
<li>Invoke the image generator program using the JCL provided in SYS1.SCUNJCL(CUNJIUTL).
Use the conversion statements specified in SYS1.SAMPLIB(CUNSISM6).
CUNSISM6 contains all the conversion statements needed to build the
pre-built image.</li>
<li>After building the image, specify the image name in the CUNUNI<var class="pv">xx</var> parmlib
member.</li>
<li>Specify the corresponding UNI=<var class="pv">xx</var> parameter in your IEASYS<var class="pv">xx</var> parmlib
member and re-IPL.</li></ol></div></div>
<p><strong>Reference information:</strong> For more information
about how to create an image, see the section on Creating a Unicode
Services Environment in >z/OS Unicode Services User&rsquo;s Guide and Reference</a>.</p>
<h3 id="etcwork">Remove classification rules with the ETC work qualifier</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R12, the workload management (WLM) service
definition no longer supports the work qualifier EWLM transaction
class name (ETC) for classification rules of the subsystem type EWLM.</p>
<p>If the activated service definition contains classification rules
with qualifier type ETC, they are simply ignored by WLM. However,
the next time you modify the classification rules for subsystem EWLM
with the WLM ISPF Application, you have to delete the ETC rules before
you save your modifications. Although z/OS V1R12
disregards classification rules with the ETC work qualifier, we recommend
that you remove them. If you do not remove the rules, you will have
to delete them the next time you use the WLM ISPF application to modify
the EWLM subsystem type. <a id="idx366"></a><a id="idx367"></a></p>
<table id="wq244" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended, otherwise you will have
to delete the classification rules the next time you use the WLM ISPF
application to modify the EWLM subsystem type.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If your WLM service definitions
contain classification rules for subsystem type EWLM with the ETC
work qualifier, start the WLM ISPF application and choose the Classification
Rules option from the Definition Menu. Use the Modifiy option (3)
for the IBM-supplied subsystem type EWLM. Delete all rows with the
ETC qualifier type by using the Delete row Option (D).</p>
<p><strong>Reference information:</strong> For a description
of how to modify a WLM service definition, see  >z/OS MVS Planning: Workload Management</a>.</p>
<h3 id="sfmpoli">Update the SFM policy to control automatic termination of impaired
critical members</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, a member of an XCF group can identify
itself as being critical to the operation of the group or the system.
 If a critical member appears to be inoperative (impaired) and the
condition persists long enough,  XCF automatically terminates the
member in an attempt to resolve the problem. For a member that is
critical to the operation of the system, this termination causes the
system to be removed from the sysplex. For more information about
XCF groups, see >z/OS MVS Setting Up a Sysplex</a>.</p>
<p>Members of the SYSGRS group, for instance, are critical to the
operation of the system. If any GRS member is impaired, ENQ processing
is likely impacted throughout the sysplex. Failure to perform ENQ
processing in a timely fashion has significant negative impact.  Thus
if a GRS member appears to be impaired, XCF will automatically remove
from the sysplex, the system on which that member resides.</p>
<p>You can set the MEMSTALLTIME parameter in your sysplex failure
management (SFM) policy to control how long XCF allows a critical
member to persist in an impaired state before it initiates termination
of the member (or the member's system).  If the MEMSTALLTIME specification
resolves to NO (either implicitly or explicitly), XCF will terminate
an impaired critical member if the condition persists as long as the
failure detection interval (INTERVAL) of the system on which the member
resides, or if the condition persists as long as two minutes, whichever
is greater. To determine which groups are using the critical support,
issue the appropriate XCF display command.</p>
<p>The MEMSTALLTIME parameter also determines how long XCF allows
a signalling sympathy sickness condition to persist before terminating
a stalled group member that is contributing to the problem.</p>
<p>The MEMSTALLTIME parameter indicates the number of seconds that
XCF should wait before it terminates a member that is impacting the
sysplex.  A MEMSTALLTIME value of 120 (two minutes)  seems to suit
many installations as it provides some additional time for the system
to resume normal  operation, yet allows automatic action to resolve
the problem before the sympathy sickness condition critically impacts
the sysplex.  Installations that resolve such conditions through manual
intervention sometimes use a higher value to allow time for such intervention
to be accomplished. Installations that are less able to tolerate sympathy
sickness conditions sometimes set lower values.</p>
<table id="wq245" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended when you want to designate
how long XCF will wait before initiating termination of the impaired
critical members.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you do not have an SFM
policy, or if the SFM policy specifies (either implicitly or explicitly)
MEMSTALLTIME(NO), determine if the default time that XCF will wait
before terminating an impaired critical member is acceptable.  The
default time is the maximum of the effective failure detection interval, or
two minutes, whichever is greater.</p>
<p>If you have an SFM policy that specifies MEMSTALLTIME other than
NO, confirm that the current specification is also acceptable for
the termination of critical members.</p>
<p>If changes are necessary, take the following steps:</p>
<ol type="1">
<li>As needed, use the IXCMIAPU utility to create a function couple
data set for SFM policies.</li>
<li>Use the IXCMIAPU utility to create or modify an SFM policy with
an acceptable MEMSTALLTIME specification.</li>
<li>Issue the SETXCF command to activate the desired SFM policy.</li></ol>
<div>
<div class="notelisttitle" id="wq247">Notes:</div>
<ol type="1">
<li>On a sysplex-wide reIPL, the policy cannot be activated
until some system is up far enough to process the SETXCF command.</li>
<li>For an existing sysplex, the appropriate SFM policy must be activated
before the z/OS V1R12 system
is IPLed to ensure that the z/OS V1R12
system will use the desired MEMSTALLTIME specification.</li>
<li>If you currently specify or default to an effective action of
MEMSTALLTIME(NO), activating a policy with MEMSTALLTIME(n) might change
the behavior of the existing sysplex (since XCF is then permitted
to terminate stalled XCF members that are causing signaling sympathy
sickness).
<p>Enhance operational and automation procedures to deal
with stalled or impaired members. Relevant messages to consider for
dealing with stalled members in general, and signaling sympathy sickness
specifically, are IXC431I, IXC432I, IXC430E, IXC640E, IXC660E, IXC631I,
and IXC632I. Additional messages to consider for impaired members
are IXC633I, IXC634I, IXC635E, IXC636I. For more information about
XCF messages, see <a href="../com.ibm.zos.r13.ieaf100/hansick.htm">Handling
Signaling Sympathy Sickness</a> in >z/OS MVS Setting Up a Sysplex</a>.</p></li>
</ol></div>
<p><strong>Reference information:</strong> For details about
using SFM policy see  >z/OS MVS Setting Up a Sysplex</a>.</p>
<h3 id="reusasi">Accommodate new REUSASID default</h3>
<p><strong>Description:</strong> In z/OS V1R9, the REUSASID(YES|NO) parameter in parmlib
member DIAG<var class="pv">xx</var> was introduced with a default of NO. Starting
with z/OS V1R12, the default
is changed to YES.  <a id="idx368"></a><a id="idx369"></a></p>
<p>When a reusable ASID is requested by the START command or the ASCRE
macro, this reusable ASID is assigned if REUSASID(YES) is specified
in DIAG<var class="pv">xx</var>. If REUSASID(NO) is specified in DIAG<var class="pv">xx</var>,
an ordinary ASID is assigned. The default is REUSASID(YES).  The use
of reusable ASIDs might result in system 0D3 abends, if products or
programs have not been upgraded to tolerate reusable ASIDs.</p>
<table id="wq249" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes. If this migration action is not taken,
the 0D3 abends might occur with downlevel products that provide no
toleration support for reusable ASIDs. Because reusable ASIDs
have been available since z/OS V1R9,
it is reasonable to expect that the current levels of products are
tolerant of reusable ASIDs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>On z/OS V1R11 systems,
specify REUSASID(YES) in the parmlib member DIAG<var class="pv">xx</var>. On z/OS V1R12 and z/OS V1R13 systems, keep REUSASID(YES), or allow
it to default to YES. You can use the SET DIAG=<var class="pv">xx</var> command
to change the REUSASID (YES|NO) option.</li>
<li>Verify that no 0D3 abends occur as a result.</li>
<li>If 0D3 abends do occur, apply appropriate maintenance to the affected
code.</li>
<li>If this is not possible, specify REUSASID(NO) in DIAG<var class="pv">xx</var> 
on z/OS V1R13 to override the
new default of REUSASID(YES).</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about reusable ASIDs, see >z/OS MVS Programming: Extended Addressability Guide</a>.</li>
<li>For more information about the REUSASID parameter in the parmlib
member DIAG<var class="pv">xx</var>, see >z/OS MVS Initialization and Tuning Reference</a>.</li></ul>
<h3 id="autoroo">Review the list of WTORs in parmlib member AUTOR00</h3>
<p><strong>Description:</strong> In z/OS V1R12, the DDDEF&quot;d PARMLIB provides an
AUTOR00 member. This member should be found in your parmlib concatenation
during IPL and will result in auto-reply processing being activated.
If the WTORs listed in AUTOR00 are automated by your existing automation
product, ensure that the replies in AUTOR00 are appropriate.<a id="idx370"></a></p>
<p></p>
<table id="wq251" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Examine the WTOR replies in
the AUTOR00 parmlib member. If the replies or delay duration are not
desirable, you can create a new AUTOR<var class="pv">xx</var> parmlib member and
make corresponding changes. Also compare the replies to what your
automation product would reply to these WTORs. Make sure that the
AUTOR00 replies are in accordance with the replies from your automation
product. IBM does not recommend
making updates to AUTOR00, because updates to AUTOR00 might be made
by the service stream or in new z/OS releases.</p>
<div>
<div class="notelisttitle" id="wq252">Notes:</div>
<ol type="1">
<li>If you have created an AUTOR<var class="pv">xx</var> parmlib member, update
the IEASYS<var class="pv">yy</var> parmlib member that you use for IPL. Add the
following statement to the IEASYS<var class="pv">yy</var> member:  
<pre class="xmp"><code>AUTOR=(xx,00)</code></pre>Here <var class="pv">xx</var> corresponds
to the AUTORxx parmlib member that you created.  The IEASYS<var class="pv">yy</var> members
specifying AUTOR cannot be shared with prior z/OS releases. If you only need the default AUTOR00
settings, you can omit specifying AUTOR= in IEASYS<var class="pv">yy</var>, and
other z/OS levels can continue
to use IEASYS<var class="pv">yy</var>. Even if AUTOR= is not specified in IEASYS<var class="pv">yy</var>,
AUTOR00 is used if it exists.
<p>If you have automation already in
place for a WTOR and that WTOR now appears in AUTOR, the AUTOR version
still can be used. Review the WTORs in AUTOR and your automation;
either remove the WTOR from AUTOR or from your automation.</p></li>
<li>On a z/OS V1R11
system with APAR OA35929, you can specify the AUTOR keyword in IEASYS<var class="pv">xx</var> with
the WARNUND specification, but the AUTOR keyword is ignored, and the
IPL will continue. If you do not specify WARNUND and you have specified
AUTOR on z/OS V1R11, the IPL
will be stopped.</li>
<li>If you don't want to activate auto-reply processing, specify AUTOR=OFF
in the parmlib member IEASYS<var class="pv">xx</var> or in response to message
IEA101A SPECIFY SYSTEM PARAMETERS. It is not recommended that you
remove AUTOR00 from parmlib, because service or new releases might
reinstall AUTOR00. If there is no AUTOR00 member in parmlib, auto-reply
is not activated and the following messages are produced:
<pre class="xmp"><code>CNZ2600I AUTO-REPLY POLICY ATTEMPTING TO USE AUTOR=00.          
IEA301I AUTOR00 NOT FOUND IN PARMLIB                               
CNZ2601I AUTO-REPLY POLICY NOT ACTIVATED. 
NO ENTRIES SPECIFIED</code></pre></li>
<li>If you do not specify the WARNUND option, the IEASYSyy members
specifying AUTOR=OFF cannot be shared with earlier z/OS releases.</li>
</ol></div>
<p><strong>Reference information:</strong> For more information
about the AUTOR<var class="pv">xx</var> and IEASYS<var class="pv">yy</var> parmlib members,
see >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h3 id="logrecsum">Adjust LOGRECSUMMARY statement value in CEAPRMxx member</h3>
<p><strong>Description:</strong> As of z/OS V1R12, the default and maximum values are changed
for this parmlib statement from 24 to 4 hours. Parmlib members that
use the old default value (24) are subject to a parsing error message
(ASA008I).  CEA automatically adjusts the value to the new default
value (4) and continues processing.   <a id="idx371"></a><a id="idx372"></a></p>
<p></p>
<table id="wq254" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No,  but recommended to avoid the ASA008I messages
received during parsing of the CEAPRMxx member.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>The system is not impacted.  CEA automatically
adjusts to the new supported default and continues with IPL if anything
higher than 4 hours is encountered. The parsing error is effectively
ignored by the system.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review which CEAPRMxx  member
you are using, if any, that overrides CEAPRM00.  If you are using
an override parmlib member, specify the new value of (04:00:00) for
the LOGRECSUMMARY statement instead of the unsupported value of 24.
There are three LOGRECSUMMARY statements to adjust in a CEAPRMxx member:
one for the SLIP, DUMP, and ABEND operands on the DUMPCAPTURETIME
statement.  Adjust all three to be within the supported maximum of
4 hours.</p>
<p><strong>Reference information:</strong> For more information,
see the CEAPRMxx parmlib member in <cite></cite>.</p>
<h2 id="wq255">BCP actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes BCP migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx373"></a><a id="idx374"></a><a id="idx375"></a><a id="idx376"></a><a id="idx377"></a>
<h3 id="javacpm">Update Capacity Provisioning Manager parameters to use CIM
client for Java Version 2</h3>
<p><strong>Description:</strong> If you set up your Provisioning
Manager in z/OS V1R11 or earlier,
and you are not using the default installation path /usr/lpp/wbem/jclient for
your CIM component, you need to set up the Capacity Provisioning Manager
for the use of CIM Client for Java Version
2.<a id="idx378"></a><a id="idx379"></a></p>
<table id="wq256" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning Manager
and are not using the default installation path for your CIM component.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong>  </p>
<ul>
<li>The Provisioning Manager user CPOSRV needs read access to CIM
Client for Java Version 2 sblim-cim-client2.jar. These access rights are usually
sufficient by default. If the current access rights are insufficient,
you must set the "other" read access permissions of the file accordingly,
using the UNIX command chmod,
for example, <span class="pk">chmod o+r /usr/lpp/wbem/jclient/sblim-cim-client2.jar</span>.
Note that this command must be issued by a user with appropriate <span>authorization</span>.</li>
<li>If your CIM installation directory is not at the default location,
you need to add the location of the CIM Client for Java Version 2 sblim-cim-client2.jar to
the CLASSPATH entry. If you have already specified the location of
a previous version of the CIM Client for Java,
you need to add the location of CIM Client for Java Version 2 before the location of the previous
version of CIM Client for Java.
The CLASSPATH is specified in the ENV member of the Provisioning Manager
runtime environment data set, prefix.PARM.  The prefix for the data
set name is the high-level qualifier of the Capacity Provisioning
Manager parameters data set  and the name of the domain managed by
the Capacity Provisioning Manager.  For example, with the default
values, the data set name would be CPO.DOMAIN1.PARM.</li></ul>
<p><strong>Reference information:</strong> For additional information
about Setting up a Capacity Provisioning domain,  see >z/OS MVS Capacity Provisioning User&rsquo;s Guide</a></p>
<h3 id="grsficon">Migrate to GRS-managed FICON CTCs</h3>
<p><strong>Description</strong>: Prior to OA38230, GRS could
only manage CTCs running in basic mode. Starting with APAR OA38230
(on z/OS V1R11, z/OS V1R12, and z/OS V1R13), GRS can additionally manage FICON CTCs (FCTC), which run in
extended mode.<a id="idx380"></a></p>
<p>Migrate GRS-managed basic-mode CTCs to GRS-managed FICON CTCs in order to run in
extended mode. Note that GRS star continues to be the recommended
configuration for global ENQ/DEQ processing because of its better
performance and overall reliability, availability, and serviceability
(RAS).  If the installation requires a GRS ring, IBM suggests that the GRS complex equals the sysplex,
as it provides a more robust transport layer for its communications.</p>
<table id="wq257" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13, z/OS V1R12 and z/OS V1R11 with APAR OA38230</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13, z/OS V1R12 and z/OS V1R11 without APAR OA38230.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>
<p>No, but recommended because it might be required
in the future, as part of the hardware statement of direction. See
the hardware release memorandum RFA z196 for further information. <a href="http://www-01.ibm.com/common/ssi/rep_ca/0/897/ENUS110-170/ENUS110-170.PDF">http://www-01.ibm.com/common/ssi/rep_ca/0/897/ENUS110-170/ENUS110-170.PDF</a></p>
<p>This
migration action only applies to installations where GRS directly
manages CTCs as specified in GRSCNF<var class="pv">xx</var>. There are two applicable
configurations:</p>
<ul>
<li>A GRS Ring where the GRS complex is greater than the sysplex,
or</li>
<li>A GRS ring that does not utilize sysplex communications at all.</li></ul>
<p>If you are running GRS Star, or using embedded XCF communications
links rather than GRS-managed CRCs, this migration action is
not applicable to you.</p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>There are coexistence PTFs for the GRS-managed FICON CTCs. See the migration
actions <a href="#coxptfs">Install coexistence and fallback PTFs</a>.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Until each system that communicates with another
system is configured to use FCTCs, GRS will be unable to use that
FCTC.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IBM Health
Checker for z/OS check GRS_MODE
can help you determine if you are running GRS Star or ring. If this
check indicates that you are running GRS Star (the recommendation),
then this migration action is not applicable to you. If this check
indicates that you are running GRS ring, then this migration action
may be applicable as described in the section above: &quot;Is this
migration action required?&quot;</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> There are two separate methods
to migrate to the updated GRSCNFxx members with the additional FICON CTC, depending on the needs
of the installation.</p>
<p><strong>Initial preparation:</strong></p>
<p>Regardless of the migration method chosen, there is some initial
preparation:</p>
<ul>
<li>Apply the program temporary fixes (PTFs) for OA38230 to all the
systems before an IPL of any system.</li>
<li>Make sure all FICON CTC
adapters, in addition to the existing ESCON basic
channel-to-channel (BCTC) adapters, have the proper configuration
and connection to each z/OS system
in the GRS complex.</li>
<li>Determine the FICON CTC
adapter device numbers from the hardware configuration.</li>
<li>Add the corresponding FICON CTC
device numbers to the end of the existing list for GRSCNFxx members
used across the complex, as shown in the example.</li></ul>
<p>GRS-managed CTC devices are solely for the use of GRS and cannot
be added to the system dynamically. The CTC devices must be defined
in GRSCNFxx at IPL time. Also recall that the order of the CTC devices
listed in GRSCNFxx is significant for any given remote system. The
CTC device listed last is the first CTC device considered for primary
usage. Provided GRS' initialization of that CTC device is successful,
the next-to-last CTC device gets set up as an alternate, the next
as an additional alternate, and so forth. If your installation is
testing the GRS FICON CTC
support on hardware that supports ESCON, IBM recommends adding, rather than
replacing, the FICON CTC device
numbers below the existing CTC device numbers, as shown in example.</p>
<p><strong>Example:</strong></p>
<p>A GRSCNFxx CTC example.</p>
<pre class="xmp"><code>/*********************************************************************/
/* IN THIS EXAMPLE,                                                  */
/* DEVICE NUMBERS BETWEEN 0500 AND 05FF ARE BCTCS                    */
/*                        8100 AND 81FF ARE FCTCS                    */
/*********************************************************************/
GRSDEF                                                                 
  MATCHSYS(*)                                                          
  CTC(5C0)  /* prospective 3rd alternate - BCTC                      */
  CTC(5DF)  /* "           2nd alternate - BCTC                      */
  CTC(8100) /* "           alternate     - FCTC                      */
  CTC(811F) /* "           primary       - FCTC                      */</code></pre>
<p>There are two separate ways to migrate to the updated GRSCNFxx
members with the additional FICON CTC
devices, depending on the needs of the installation.</p>
<p><strong>Migration method: rolling IPL</strong></p>
<p>Migrating to FICON CTC
communication means a planned outage because at least one system remains
active in the current GRS ring throughout the migration. The advantage
of performing a rolling IPL is that it allows for better availability.</p>
<p>Use the following procedure to minimize the chance of a ring disruption
in the migration of GRS-managed CTC communication:</p>
<ol type="1">
<li><strong>Follow your normal procedures for bringing down
the system and preparing to IPL.</strong> Don&rsquo;t forget to enter the
Z EOD command to write buffered system management facilities (SMF)
records, and system log and LOGREC data, and wait for message IEE3341:
HALT EOD SUCCESSFUL.</li>
<li><strong>Quiesce the systems from the ring.</strong> On any
system, enter the VARY GRS(X),QUISCE command. Wait for message ISG013I;
SYSTEM X QUIEXCED GLOBAL RESOURCE SERIALIZATION. The VARY GRS(X),QUISCE
command is important because it prevents a ring disruption from removing
the QUIESCED system. You can only use VARY GRS(X),QUIESCE when there
is at least one XCF=local or monoplex system in the complex using
CTC communication.</li>
<li><strong>Stop the system.</strong> Now it is safe to stop
system X. Do so by initiating a system reset on the hardware management
console (HMC). For Parallel
Sysplex, the sysplex failure management (SFM) policy and the
status update missing intervals (specified on the INTERVAL keyword
in COUPLExx) start counting down as soon as you use the system reset.</li>
<li><strong>Purge the system from the ring.</strong> After system
X stops, it is an XCF=local system or a monoplex. On any system, issue
VARY GRS(X),PURGE. If system X is a member of a sysplex, issue VARY
XCF,X,OFFLINE and respond to the prompts as usual. In either case,
wait for message ISG013I: SYSTEM X PURGED FROM GRS COMPLEX, which
means system X is removed from the ring.</li>
<li><strong>IPL with a new GRSCNFxx.</strong> IPL system X. When
the system is ready, issue D GRS to verify the system (and the other
systems). It should show up as &quot;ACTIVE&quot; in the existing GRS
ring. If the JOIN process on the existing ring fails, make sure GRSCNFxx
is correct and the purge of the previous instance from the ring was
successful. Try this step again.</li>
<li><strong>Check the CTC devices.</strong> Verify that the D
GRS output lists the new CTC device numbers as IN-USE, ALTERNATE
or conditionally QUIET. If the CTC device is IN-USE or ALTNERATE,
the TARGET SYSNAME field must be accurate. If a CTC status is QUIET,
it is online, but the other side of the CTC device is not communicating.
If the system on the other side of the CTC device has not been re-IPLed
to pick up the new CTC definitions, then QUIET status is expected.
Scenario II in <a href="#rollipl">Figure 1</a> shows that GRS will not attempt
to use a new CTC device until the system at the other side of the
link is re-IPLed to pick up its corresponding CTC device. If
all of the systems are running with the new CTC device, it is unusual
that the CTC device remains QUIET. If there are one or more QUIET
CTC devices, look for a CTC problem on the system at the other end
of the link. If the CTC device is unexpectedly DISABLED, look for
the corresponding ISG046E message from the SYSLOG. There is probably
a parmlib member or device configuration issue. After you address
the issue, try to VARY the device online.</li>
<li><strong>Repeat steps 1 through 6</strong> for each system
in the GRS ring.</li></ol>
<p></p>
<div class="fignone" id="rollipl"><span class="figcap">Figure 1. Example of a rolling IPL on a three-system GRS ring</span>
<div class="mmobj">
<img src="e0z2grs1.gif" alt="REQTEXT" /></div></div>
<p><a href="#rollipl">Figure 1</a> illustrates how the rolling IPL eventually
starts using the new FICON CTC
(FCTC) devices. After the first system is restarted with the original
CTC and FCTC devices (scenario II in <a href="#rollipl">Figure 1</a>), GRS
continues to use the original CTC device and JOIN the existing GRS
ring. However, as the second and third system are restarted (scenario&rsquo;s
III and IV in <a href="#rollipl">Figure 1</a>), GRS uses the FCTC rather than
the BCTC because on IPLing system, GRS always tries to initialize
the CTC devices in last-to-first order as they appear
in GRSCNFxx.</p>
<p><strong>Migration method: complex-wide IPL</strong></p>
<p>A GRS complex-wide IPL depends on the installation&rsquo;s
policies and procedures regarding planned outages of that scale. The
preparation is the same with regard to applied PTF, FICON setup, and GRSCNFxx settings. The orderly
shutdown can use the same initial steps to avoid ring disruptions.</p>
<p>In the case of a mixed complex, it is important for the last system
to be an XCF=local or monoplex system. Whenever a mixed GRS complex
transitions into a pure sysplex, VARY GRS(X) is no longer allowed.
It is also recommended that you IPL that system alone with GRS=START
to establish the ring of one with all of its CTC devices QUIET before
starting the remaining systems. See <a href="#tryjoin">***</a>.</p>
<p id="tryjoin"><strong>TRYJOIN Warning</strong></p>
<p>Do not use GRS=TRYJOIN if any systems in the GRS complex use GRS-managed
CTC communication. When the GRS complex equals the sysplex, the TryJoin
option is planned to resolve correctly. In a mixed up ring or a ring
where GRS manages all of its CTC communication directly, a single
system should specify GRS=START and the remainder GRS=JOIN. Otherwise,
there exists a race condition for the initializing systems to form
a split ring where data integrity is compromised. This is still true
with FICON CTC support.</p>
<p><strong>Reference information:</strong></p>
<ul>
<li>For more information, see <cite></cite>.</li>
<li>For more information on CTC definitions, see:
<ul>
<li><cite></cite></li>
<li><cite></cite></li>
<li><cite></cite>.</li></ul></li></ul><a id="idx381"></a><a id="idx382"></a><a id="idx383"></a>
<h3 id="grsauthql">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R13, global resource serialization (GRS)
provides an additional list of qnames that are conditionally authorized:
ARCDSN, ARCBTAPE, ARCGPA, ARCBACV, and ARCMIGV. You can set the new
AUTHQLVL parameter in the GRSCNF<var class="pv">xx</var> parmlib member to indicate
whether the system is to recognize the second list of authorized qnames
in addition to the original list. The value is either 1 (default)
or 2.</p>
<p>The AUTHQLVL setting of 1 (default) denotes that the existing IBM default list for authorized
qnames (that is, the list in effect for systems at z/OS V1R12 and earlier) is in effect for the system
in the global resource serialization (GRS) complex. The AUTHQLVL setting
of 2 denotes the addition of the five new qnames (ARCDSN, ARCBTAPE,
ARCGPA, ARCBACV, ARCMIGV) to the authorized qname list and provides
a higher level of protection; however, it can cause some products
to fail. An unauthorized program issuing ENQ or DEQ requests for any
of these qnames when AUTHQLVL of 2 is in effect will get ABEND338
or ABEND330, respectively.  ISGENQ requests with COND=NO will get
similar ABENDs and ISGENQ requests with COND=YES will get return code
8, reason code xxxx081E, ISGENQRsn_NotAuthorizedForQName.</p>
<table id="wq259" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, to protect authorized programs utilizing
these qnames from denial-of-service attacks.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check GRS_AUTHQLVL_SETTING to help determine
your installation&rsquo;s need for authorized qname protection.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Products that are designed to interact with resources that have
these qnames need to run authorized.  In order to help determine if
your installation has any of these products running on your system,
there is a new AUTHQ2 filter on the EQDQ Monitor.  Before the new
AUTHQLVL is increased to 2, this filter shows ENQ requests that are
made with any of these new qnames from an unauthorized program.</li>
<li>The AUTHQLVL setting in GRSCNF<var class="pv">xx</var> refers to a specific
system.  A rolling IPL is required to ensure consistency across the
GRS complex.  The increased AUTHQLVL value can be tested on one system
but only for ENQ requests initiated on that system. The AUTHQLVL=2
migration process is not complete until all systems across the GRS
complex are at 2.</li>
<li>If ABEND338 or ABEND330 occurs from the change because one of
the required products is missed, the <span class="pk">SETGRS</span> command supports
a fallback to 1 on any given system by issuing <span class="pk">SETGRS AUTHQLVL=1</span>;
however, you cannot dynamically increase the AUTHQLVL.  Another IPL
is required. As with other SETGRS keywords that require UPDATE access
to an OPERCMDS profile matching an MVS.SETGRS.<var class="pv">xxx</var> profile
name, downgrading the AUTHQLVL to 1 through the SETGRS command in
an OPERCMDS environment requires update access to a profile of the
form MVS.SETGRS.AUTHQLVL</li></ol>
<p><strong>Reference information:</strong> For details about
authorized qnames, see >z/OS MVS Planning: Global Resource Serialization</a>.</p>
<h3 id="cmdsabe">Examine use of the CMDS ABEND command</h3>
<p><strong>Description:</strong> <span>Before z/OS V1R13, the CMDS ABEND command
ended an executing command if the command was hung. In z/OS V1R12, or with the PTFs for
APAR OA30527 installed on z/OS V1R11
and z/OS V1R10, the command
processors were allowed to specify the new non-abendable attribute
to set themselves non-abendable. When the new attribute was specified
for a target command, the CMDS ABEND command rejected with message
CNZ6002I. The CMDS ABEND attempted to terminate the hung command.</span>.
Starting in z/OS V1R13, the
new parameter FORCE is added to the CMDS command so that a CMDS FORCE
specification overrides the non-abendable attribute and the command
will be terminated as it is today. Separating the ABEND and FORCE
requests allow different RACF profiles
to be defined so that installations can allow CMDS ABEND, but not
CMDS FORCE. FORCE is intended to be used where the only alternative
is to re-IPL the system.</p>
<p></p><a id="idx384"></a>
<table id="wq261" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use the CMDS ABEND
command or have automation that does.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Automation that uses the CMDS
ABEND command is affected because the termination of a running command
can be rejected. For some commands, this rejection is important because
it can prevent a system or sysplex outage. If you use the CMDS ABEND
command or have automation that does, certain commands will no longer
be terminated by the CMDS ABEND command.</p>
<ul>
<li>If you must terminate a command, continue to use the CMDS ABEND
command. If the command is in a state making it non-abendable, use
the CMDS FORCE command after understanding the following recommendations
associated with the FORCE parameter: 
<ul>
<li>After issuing CMDS FORCE, you might have to re-IPL the system
or, depending on the command being terminated, a sysplex-wide IPL
may be required.</li>
<li>You should ensure that the target command is hung and not just
requiring additional time to complete.</li></ul></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about the CMDS command, see >z/OS MVS System Commands</a>.</li>
<li>See message CNZ6002I COMMAND <em>command</em> WITH
ID id NOT ABENDABLE in >z/OS MVS System Messages, Vol 4 (CBD-DMO)</a>.</li></ul>
<h3 id="rtdpfa">Ensure Runtime Diagnostics is installed before invoking Predictive
Failure Analysis</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R13, Predictive Failure Analysis (PFA) calls
Runtime Diagnostics to analyze and report insufficient metric activity
from the following checks:</p>
<ul>
<li>PFA_ENQUEUE_REQUEST_RATE</li>
<li>PFA_MESSAGE_ARRIVAL_RATE</li>
<li>PFA_SMF_ARRIVAL_RATE</li></ul>
<p>Therefore, PFA requires the Runtime Diagnostics address space (HZR)
to be active on any system it analyzes. <a id="idx385"></a><a id="idx386"></a><a id="idx387"></a></p>
<table id="wq262" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you plan on using the following checks:
<ul>
<li>PFA_ENQUEUE_REQUEST_RATE</li>
<li>PFA_MESSAGE_ARRIVAL_RATE</li>
<li>PFA_SMF_ARRIVAL_RATE</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If RTD isn't running and PFA calls it, the call
to RTD returns with a return code of 12 and a reason code of 3074
(C02), and PFA processing skips the potential exception because it
could not be confirmed through RTD (as in previous releases without
this z/OS V1R13 enhancement).
If or when RTD ever becomes active, the calls will become successful.
 The return code and reason code are logged in the systemnameRUN.LOG
for the check, as follows: 
<pre class="xmp"><code>Calling to determine too low 
Return code = 0000000C 
Reason code = 00000C02</code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure the HZR is defined
as a system address space. See <a href="#commndxx">Start Runtime Diagnostics at system initialization</a> .</p>
<p><strong>Reference information:</strong> For complete details
about using Runtime Diagnostics, see the topics <a href="../com.ibm.zos.r13.e0zk100/rtdin.htm">Runtime Diagnostics overview</a> and <a href="../com.ibm.zos.r13.e0zk100/prfail.htm">Predictive Failure Analysis overview
and installation</a> in >z/OS Problem Management</a>.</p>
<h3 id="cpccdef">Carry over your existing CPCC policy</h3>
<p><strong>Description:</strong> The Capacity Provisioning Control
Center (CPCC) can coexist with older versions of the CPCC on a workstation.
However, z/OS V1R13 CPCC uses
a different default workspace. If you want to continue using your
existing CPCC workspace, point to the respective directory during
the installation of z/OS V1R13
CPCC. It is also possible to change the workspace when the CPCC starts.<a id="idx388"></a><a id="idx389"></a></p>
<table id="wq263" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to continue using your existing
CPCC workspace.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td><span>You must run a level of the CPCC
client that corresponds to the z/OS system
that you target. </span>For example, run the z/OS V1R13 CPCC client on the workstation when interacting
with the z/OS V1R13 Capacity
Provisioning Manager, and run the z/OS V1R12
CPCC client on the workstation when interacting with the z/OS V1R12 Capacity Provisioning
Manager.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ul>
<li>Install z/OS V1R13 CPCC
using information in documentation referenced below.
<div>
<div class="notetitle" id="wq264">Note:</div>
<div class="notebody">With z/OS V1R13, the location of the
default workspace changes from, for example, 
<br />
<samp class="xph">C:\Documents and Settings\user\Application Data\IBM\IBM
Capacity  Provisioning Control Center</samp>     
<p>to</p>
<br /><samp class="xph">C:\Documents
and Settings\user\Application Data\IBM\IBM Capacity Provisioning Control
Center V1R13\</samp>  
<p>The actual directories depend on the Windows version that you are
using.</p></div></div></li>
<li>If you want to continue using your existing (pre-z/OS V1R13) CPCC
workspace, point to the desired workspace during the installation
process. You can also switch the workspace at a later time by navigating
to the desired workspace when the CPCC starts.</li></ul>
<p><strong>Reference information:</strong> For more information
about installing and uninstalling CPCC, see >z/OS MVS Capacity Provisioning User&rsquo;s Guide</a>.</p>
<h3 id="binder1">Evaluate applications that parse AMBLIST command LISTLOAD or
LISTIDR output</h3>
<p><strong>Description:</strong> </p>
<ol type="1">
<li>Prior to z/OS V1R12, the
AMBLIST command LISTLOAD output for load modules, in the MODLIST area
of the output, AMBLIST printed only the hexadecimal representation
of TEXT records.
<p>Beginning with z/OS V1R12,
AMBLIST command LISTLOAD output for load modules is made to work similarly
to the same output for program objects.  In particular, the output
now includes the TEXT records output in EBCDIC format to the right
of the hexadecimal representation.  This also means that some of the
columns for the hexadecimal output have been shifted.</p></li>
<li>Prior to z/OS V1R12, the
AMBLIST commands LISTLOAD and LISTIDR output header for UNIX program objects printed the
constant <strong>**UNIX**</strong> for both MEMBER NAME and LIBRARY,
in the output header for each processed UNIX program
object.
<p>Beginning in z/OS V1R12,
AMBLIST commands LISTLOAD and LISTIDR output header for UNIX program objects display the
actual directory path name and file name of the UNIX file.  It is represented this way regardless
of whether or not the MEMBER is specified as a relative path name.
 Note that MEMBER NAME and LIBRARY still only utilize a single output
line each, therefore, if either exceeds the number of allotted characters
they will be truncated on the left and preceded by two periods and
a space (.. ).</p></li></ol><a id="idx390"></a>
<table id="wq266" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your application depends on the output
generated by the AMBLIST command LISTLOAD or LISTIDR control statement
processing.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Output from the AMBLIST command
is not an intended programming interface.</p>
<ol type="1">
<li>Evaluate applications that parse AMBLIST command LISTLOAD output
to ensure that either there is no dependency on the TEXT output alignment
or the additional data to the right of the hexadecimal output.</li>
<li>Evaluate applications that parse AMBLIST command LISTLOAD or LISTIDR
output to ensure that there is no dependency on either the MEMBER
NAME or LIBRARY in the output header being the constant <strong>**UNIX**</strong> or
any other particular format.</li></ol><p class="indatacontent">To reduce future impact and maintenance, IBM suggests migrating the parsing routines or applications
to use an IBM provided programming
interface such as the Program Management APIs.  See <a href="../com.ibm.zos.r13.ieab200/callint.htm">Using the binder application
programming interfaces (APIs)</a> in>z/OS MVS Program Management: Advanced Facilities</a>.</p>
<p>The following example shows the TEXT output from LISTLOAD OUTPUT=MODLIST
of a load module (note that the MODLIST output is included with other
output specifications, including when the OUTPUT option is not specified).
 The output for load modules now has the same alignment as for program
objects, except that the offset field for load modules continues to
6 characters wide whereas it is 8 characters wide for program objects:</p>
<ul>
<li>Before z/OS V1R12:
<pre class="xmp"><code>RECORD# 6                                            T E X T
000000 E3C1E2E3 C5E240C1 D9C540C4 C9C6C6C5  D9C5D5E3 F0F1F2F3 F4F5F6F7 F8F9F0F1
000020 F2F3F4F5 F6F7F8F9
 ******END OF LOAD MODULE LISTING</code></pre></li>
<li>With z/OS V1R12:
<pre class="xmp"><code>RECORD# 6                                            T E X T
000000 E3C1E2E3 C5E240C1 D9C540C4 C9C6C6C5  D9C5D5E3 F0F1F2F3 F4F5F6F7 F8F9F0F1
*TASTES ARE DIFFERENT012345678901*
000020 F2F3F4F5 F6F7F8F9
*23456789                        *
 ******END OF LOAD MODULE LISTING</code></pre></li></ul>
<p>The following example shows the output header from LISTLOAD of
a UNIX program object.</p>
<ul>
<li>Before z/OS V1R12:
<pre class="xmp"><code>LISTLOAD MEMBER=llllllll/a.out
                                   *****  M O D U L E   S U M M A R Y  *****
MEMBER NAME:  **UNIX**
LIBRARY:      **UNIX**</code></pre></li>
<li>With z/OS V1R12:
<pre class="xmp"><code>LISTLOAD MEMBER=llllllll/a.out
                                   *****  M O D U L E   S U M M A R Y  *****
MEMBER NAME:  a.out
LIBRARY:      .. eeeeee/ffffffff/gggggggg/hhhhhhhh/iiiiiiii/jjjjjjjj/llllllll</code></pre></li></ul>
<p><strong>Reference information:</strong> For details about
the AMBLIST command, see >z/OS MVS Diagnosis: Tools and Service Aids</a>.</p>
<h3 id="hiscomp">Ensure analysis tools interacting with HIS output accommodate
HIS state change events</h3>
<p><strong>Description:</strong> Hardware instrumentation services
(HIS) is a function that collects hardware event data for processors
in SMF records type 113, subtype 2, as well as UNIX System Services output files. You can only use
HIS for IBM System z10 or later machines. In z/OS V1R12 (and in z/OS V1R11with the PTF for APAR
OA30486 installed), functionality is added to the HIS component
which causes changes in the output filename formats produced by HIS
(.CNT, .SMP, .MAP), as well as introducing additional lines to the
.CNT file possibly causing incompatibilities.  In addition, an increase
in SMF Type 113 records might be noticed. <a id="idx391"></a><a id="idx392"></a></p>
<p>Any tools that programmatically open the HIS output files (.CNT,
.MAP, or .SMP), and any tools that programmatically analyze the HIS
output .CNT file, should be analyzed and updated to accommodate the
new formats.</p>
<table id="wq268" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you start HIS and have programs that
analyze the HIS output.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ul>
<li>What to look for:
<ul>
<li>The new filename output format is an indication that the support
is installed.</li>
<li>The first line of the .CNT file indicates output version 2.</li>
<li>New output message HIS032I &quot;STATE CHANGE DETECTED ACTION=action.&quot;</li>
<li>An additional line in the output of DISPLAY HIS command, which
describes the action that should be taken should a state change event
occur (specified by the operator at the start of a collection run).</li></ul></li></ul>
<ul>
<li>What to do:
<ul>
<li>If programmatically opening files, ensure the new output file
format is handled.</li>
<li>If programmatically parsing the .CNT file, ensure to check the
VERSION identifier in the header. If the identifier is VERSION 2,
be prepared for the new STATECHANGE line.</li></ul></li></ul>
<p><strong>Reference information:</strong> For additional information
about HIS state change events, see >z/OS MVS System Commands</a>.</p>
<h3 id="initlod">Detect program objects that have multiple INITIAL LOAD segments</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, the binder RMODE option only applied
to the first module segment, which contains some but possibly not
all the initial load classes, though always the class wherein lies
the entry point. Subsequent segments containing other initial load
classes were not affected by the RMODE option, and thus the binder
determined the RMODE based on the attributes of the classes contained
therein. <a id="idx393"></a></p>
<p>Beginning with z/OS V1R12,
the binder RMODE option applies to all initial load classes by default.
Thus all segments containing initial load classes are affected. This
new behavior takes affect only when the RMODE binder option is specified.
Also the RMODE option has been expanded so that either the new or
previous behavior can be explicitly requested.</p>
<table id="wq269" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, with the following conditions.
<p>Only users
or ISVs that produce program object programs, which might have multiple
INITIAL LOAD segments, need to take action if all of the items listed
below are true:</p>
<ul>
<li>Program is required to reside in a program object.</li>
<li>Program has multiple segments.</li>
<li>Program has multiple initial load classes.</li>
<li>Program has mixed RMODEs.</li>
<li>Program is link-edited with the RMODE option to override the binder
default.</li></ul>
<p></p>
<div>
<div class="notetitle" id="wq270">Note:</div>
<div class="notebody">In most cases, even if a program has multiple
segments containing INITIAL LOAD classes, no action is required.</div></div></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Install compatibility PTFs for APAR OA30988
on z/OS V1R11 systems.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Above-the-line and below-the-line storage usage
might change.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To determine whether you might
be affected by this change, you can run the AMBLIST service aid against
your program objects and examine the output.  However, if you do not
explicitly specify the RMODE option when you bind the program, it
is not affected even if the following two conditions are true.</p>
<p>Run AMBLIST using the LISTLOAD control statement. Using the OUTPUT=MAP
option results in a smaller amount of output that still contains the
pertinent information.</p>
<p>The following two conditions must both be true for the program
to be affected by the new RMODE option behavior:</p>
<ol type="1">
<li> In the Module Summary, only programs that are program objects
and are
<pre class="xmp"><code>PO FORMAT:         3</code></pre>or higher are affected.</li>
<li>In the SEGMENT MAP, only programs for which there is class entry
SEGMENT 2, and TYPE INITIAL, are affected.
<div>
<div class="notetitle" id="wq272">Note:</div>
<div class="notebody">The RMODE
differs for the SEGMENT 1, INITIAL load classes, and the SEGMENT 2,
INITIAL load classes.</div></div></li></ol>
<p>Given that these two conditions are true, there are then generally
three possible situations:</p>
<ol type="1">
<li>If the RMODE option is not being specified, there is no need to
do anything, as the behavior is identical <span>to z/OS V1R11</span>.</li>
<li>If you specified RMODE=ANY, expected all segments to be RMODE=31,
but find that one segment is RMODE=24, part of the program is using
below-the-line storage.  In most cases, this is not desirable and
the new binder behavior will remedy the situation.
<p>It is possible
that you rely on having part of the program use below-the-line storage.
You can use RMODE(ANY,COMPAT) to revert to the pre-z/OS V1R12 behavior.</p></li>
<li>If you specified RMODE=24, expected all segments to be RMODE=24,
but find that one segment is RMODE=31, part of the program is using
above-the-line storage.  In most cases, this is desirable and the
new binder behavior could cause a problem by causing the program to
use more below-the-line storage.
<p>It is also possible that you rely
on having part of the program use above-the-line storage. You can
use RMODE(24,COMPAT) to revert to the pre-z/OS V1R12 behavior.</p></li></ol>
<p><strong>Reference information:</strong> For more information
about using the RMODE option, see >z/OS MVS Program Management: User&rsquo;s Guide and Reference</a>.</p>
<h3 id="pfamax">Add to the maximum number of open files under z/OS UNIX Systems
Services for PFA</h3>
<p><strong>Description:</strong> Starting in z/OS V1R13, Predictive Failure Analysis (PFA) has
two  additional checks, PFA_JES_SPOOL_USAGE and PFA_ENQUEUE_REQUEST_RATE.
These additional checks add to the number of open files for the PFA
started task id.</p>
<div>
<div class="notetitle" id="wq274">Note:</div>
<div class="notebody">If your installation has a BPXPRMxx
MAXFILEPROC value greater than 5000, this action is not required.</div></div><a id="idx394"></a>
<table id="wq275" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13 and before the start of PFA.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use PFA  and MAXFILEPROC is less
than 5000.
<p></p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> PFA requires the maximum number
of open files under z/OS UNIX System Services to be 5000
or greater. You can increase the value in one of two ways. The first
option is preferable: </p>
<ol type="1">
<li>Update the FILEPROCMAX field in the OMVS segment of the PFA started
task id, for example: 
<pre class="xmp"><code>TSO ALU pfauser  OMVS(FILEPROCMAX(5000))</code></pre></li>
<li>Update the BPXPRMxx MAXFILEPROC value in the parmlib member BPXPRMxx.</li></ol>
<p><strong>Reference information:</strong> For more information
about the MAXFILEPROC value, see <cite></cite>.</p>
<h1 id="ad1coms">Communications Server migration actions</h1>
<p>This topic describes migration actions for base element Communications
Server.</p><a id="idx395"></a>
<h2 id="wq277">Communications Server actions to perform before installing z/OS V1R13</h2>
<p>This topic describes Communications Server migration actions that
you can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are made.</p><a id="idx396"></a><a id="idx397"></a><a id="idx398"></a><a id="idx399"></a>
<h3 id="ftpdaemon">IP Services: Accommodate new format of FTP daemon console messages
that no longer are prefixed with '+'</h3>
<p><strong>Description:</strong> Before V1R13, FTP daemon console
messages were prefixed with a '+' status indicator. Beginning in V1R13,
these messages are no longer prefixed with the '+' status indicator.</p>
<p><a id="idx400"></a><a id="idx401"></a><a id="idx402"></a></p>
<table id="wq278" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have message automation that expects
to see the &rsquo;+' character.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<p>Adjust your message automation to examine only the message ID and
text of console messages, and not to examine the status character.
The following FTP daemon console messages are affected:</p>
<ul>
<li>EZYFT59I</li>
<li>EZYFT70I</li>
<li>EZYFT72I</li>
<li>EZYFT80I</li>
<li>EZYFT81I</li>
<li>EZYFT82I</li>
<li>EZYFT83I</li>
<li>EZYFT84I</li>
<li>EZYFT86I</li>
<li>EZYFT89I</li>
<li>EZYFT90I</li>
<li>EZY2702I</li>
<li>EZY2706E</li>
<li>EZY2707E</li>
<li>EZY2714I</li></ul>
<p><strong>Reference information:</strong> For messages sent
to the MCS/SMCS consoles, see <cite></cite>.</p>
<h3 id="defidresolve">IP Services: Define a user ID for the system resolver with
an associated OMVS segment</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, the system resolver
uses z/OS UNIX services in the resolver address space. Use
of z/OS UNIX services requires the resolver to have an OMVS
segment associated with its user ID. If you do not define a user ID
for the resolver with an associated OMVS segment, the resolver initialization
will fail and the TCP/IP stack initialization will not be able to
complete. The system issues the following:</p>
<pre class="xmp"><code>IEF403I RESOLVER - STARTED - TIME=13.40.06
ICH408I JOB(RESOLVER) STEP(RESOLVER) CL(PROCESS )
OMVS SEGMENT NOT DEFINED
EZZ9301E RESOLVER ENDED ABNORMALLY
IEF450I RESOLVER RESOLVER - ABEND=SEC6 U0000 REASON=0F01C008
TIME=13.40.07
IEF404I RESOLVER - ENDED - TIME=13.40.07
*EZZ9315E TCP/IP WAITING FOR RESOLVER TO INITIALIZE </code></pre><a id="idx403"></a>
<table id="wq279" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not have a user ID defined for
the system resolver that has an associated OMVS segment, which provides
access to z/OS UNIX services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If you do not define a user ID for the system
resolver that includes an OMVS segment, the resolver initialization
will fail and the initialization of all TCP/IP stacks will be delayed.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>If you already have a user ID for the system resolver
started procedure, and you explicitly defined an OMVS segment for
the ID, or an OMVS segment was created automatically through the RACF automated assignment of unique UNIX identities support, no action
is required.</li>
<li> If you already have a resolver user ID but it does not have an
OMVS segment, you must define an OMVS segment for the resolver user
ID.</li>
<li>If you do not have a resolver user ID, you must create one that
includes an OMVS segment.</li></ol><p class="indatacontent">The following information is an excerpt of the SEZAINST(EZARACF)
sample job that you can use to define a user ID with an OMVS segment
and assign it to the system resolver started procedure. You might
need to modify the sample values that are specified in the commands
for your environment.  For example, the UID, Default Group, and Resolver
user ID values are sample values. </p>
<pre class="xmp"><code>//*=========================== RESOLVER ===============================
//*====================================================================
//*====================================================================
//*
//* Create the userid and its OMVS Segment for the daemon and
//* add it to the STARTED Class which is activated in this job.
//*
//* If you chose not to use the RACF STARTED Class,
//* the entry should be placed in the started procedures table ICHRIN03.
//*
//RESOLVER EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETROPTS CLASSACT(STARTED)
SETROPTS RACLIST(STARTED)
SETROPTS GENERIC(STARTED)
ADDUSER RESOLVER DFLTGRP(OMVSGRP) OMVS(UID(42) HOME('/')) -
NOPASSWORD
RDEFINE STARTED RESOLVER.* STDATA(USER(RESOLVER))
SETROPTS RACLIST(STARTED) REFRESH
SETROPTS GENERIC(STARTED) REFRESH
//*</code></pre>
<p><strong>Reference information:</strong> For information about
defining and assigning a user ID for started procedures, see <a href="&amp;releasenlx;.icha700/stproc.htm">Using Started Procedures</a> in >icha700t</a>.</p>
<p> For information about defining an OMVS segment, see <a href="&amp;releasenlx;.icha700/russ.htm">RACF and z/OS Unix</a> in >icha700t</a>.</p>
<p>For general information about the system resolver, see <a href="&amp;releasenlx;.halz002/defineras.htm">Steps for
defining the resolver address space</a> in >z/OS Communications Server: IP Configuration Guide</a>.</p>
<h3 id="meestorg">IP Services: Ensure storage availability for ancillary input
queue for Enterprise Extender traffic</h3>
<p><strong>Description:</strong> In z/OS V1R13, the processing of IPAQENET and IPAQENET6
INTERFACE statements is enhanced. Coding the WORKLOADQ parameter on
these INTERFACE statements now enables the QDIO inbound workload queueing
function for Enterprise Extender (EE) traffic. An additional ancillary
input queue (AIQ) is established for inbound traffic for EE if HPR=RTP
is specified as a VTAM start
option. Each AIQ increases storage utilization by an amount equal
to 36K of fixed ECSA, plus potentially the READSTORAGE value (64K
multiplied by the number of SBALs) of fixed CSM 4K data space storage.
If you have configured QDIO inbound workload queuing, you must ensure
that there is sufficient fixed ECSA and 4K CSM dataspace storage for
the AIQ for EE traffic.</p><a id="idx404"></a><a id="idx405"></a><a id="idx406"></a><a id="idx407"></a>
<table id="wq281" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you have the WORKLOADQ
parameter specified on the INTERFACE statement and you have concerns
about using additional storage.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>This migration action is required only if you
are using OSA-Express3, or later, features on an IBM zEnterpsie z196.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Each AIQ increases storage utilization by an
amount equal to 36K of fixed ECSA plus potentially the READSTORAGE
value (64K multiplied by the number of SBALs) of fixed CSM 4K data
space storage.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Verify if you are using EE; you are using EE if HPR=RTP is defined
as a VTAM start option and
if an EE XCA Major Node is defined and active. If you are using EE,
continue with steps 2-5.  If you have HPR=RTP defined as a VTAM start option but do not have
an EE XCA Major Node defined and active, continue with steps 2, 3
and 5.  Otherwise there is no increase in storage usage and no further
action is required.</li>
<li>Count the total number of OSA-Express3, and later, interfaces
that are coded with the WORKLOADQ parameter on the IPAQENET and IPAQENET6
INTERFACE statements.  Make a note of the number.</li>
<li>Verify that sufficient ECSA is available. To do this, multiply
the total number of OSA-Express3, and later, interfaces that
have inbound workload queueing enabled (you determined this number
in step 2) by 36K. The resulting number indicates how much new ECSA
is required. Use the DISPLAY CSM command to verify that sufficient
ECSA is available to enable this function.</li>
<li>Verify that sufficient real storage is available. 64-bit real
storage is used for the dataspace read buffers. Multiply the total
number of OSA-Express3, and later, interfaces that have inbound
workload queueing enabled (determined in step 2) by total number
of OSA-Express3, and later,. The maximum number of read buffers
per queue is 126. The resulting number is approximately the amount
of additional 64-bit real storage that is required for the data space
read buffers for all the new EE input queues.</li>
<li>If sufficient storage is not available, either increase the available
storage or consider defining some of the total number of OSA-Express3,
and later, INTERFACE statements with the NOWORKLOADQ parameter.</li></ol>
<p><strong>Reference information:</strong>  <a href="../com.ibm.zos.r13.halg001/nitmee1.htm">Performance improvements for
Enterprise Extender traffic</a> in >z/OS Communications Server: New Function Summary</a></p>
<h3 id="ipfips">IP Services: Permit IKE daemon running in FIPS mode to use
additional ICSF services</h3>
<p><strong>Description:</strong> In z/OS V1R13, the Internet Key Exchange (IKE) daemon
is enhanced to take advantage of new services that are provided by
Integrated Cryptographic Service Facility (ICSF) when the IKE daemon
is running in Federal Information Processing Standards (FIPS) mode.
 The new ICSF services are provided in updates to ICSF PKCS number
11 functions CSFPDVK and CSFPDMK.  ICSF now provides the following
information to the IKE daemon, each with a single call to ICSF:</p>
<ul>
<li>The derivation of the original seed key.</li>
<li>The phase 1 key set.</li>
<li>The phase 2 key set.</li></ul><a id="idx408"></a><a id="idx409"></a><a id="idx410"></a><a id="idx411"></a>
<table id="wq283" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently run the IKE daemon in
FIPS mode and if you control the access to ICSF resources in the CSFSERV
class.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>The IKE daemon now requires READ access to the CSF1DVK and CSF1DMK
resources in CSFSERV when the IKE daemon is configured to run in FIPS
mode.</li>
<li>If your security server is RACF,
issue the following commands in the order shown.  If you use a different
security server, determine and perform the equivalent steps.
<ol type="1">
<li>PERMIT CSF1DVK CLASS(CSFSERV) ID(IKED) ACCESS(READ)</li>
<li>PERMIT CSF1DMK CLASS(CSFSERV) ID(IKED) ACCESS(READ)</li>
<li>SETROPTS RACLIST(CSFSERV) REFRESH</li></ol></li></ul>
<p><strong>Reference information:</strong> For details, see the <a href="../com.ibm.zos.r13.halz002/ike4r13.htm">steps
for setting up profiles in the CSFSERV resource class</a> in >z/OS Communications Server: IP Configuration Guide</a>.</p>
<h3 id="sodbind">IP Services: Migrate from BIND 9.2.0</h3>
<p><strong>Description:</strong> IBM intends
for z/OS V1R13 to be the final
release in which the z/OS BIND
9.2.0 function is available.  If you are using this function as a
server, you must find a replacement as soon as you can.<a id="idx412"></a><a id="idx413"></a></p>
<table id="wq285" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The removal of the BIND 9.2.0 function was first
announced in February 2009. z/OS V1R13
is the final release in which the BIND 9.2.0 function is available.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if are using the BIND 9.2.0 function as
a server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use ZOSMIGV1R11_CS_BIND9 for BIND 9.2.0 to determine
if a z/OS BIND 9.2.0 name server
is in use.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you have been using z/OS BIND
9.2.0 as a caching-only name server, use the z/OS resolver DNS caching function to cache DNS
responses.</li>
<li>If you have been using z/OS BIND
9.2.0 as a primary or secondary authoritative name server, investigate
using BIND on Linux for System z or BIND on an IBM blade in a zBX.</li></ul>
<p><strong>Reference information:</strong> For details about
the resolver, see >z/OS Communications Server: IP Configuration Guide</a> and >z/OS Communications Server: IP Configuration Reference</a>.</p>
<h3 id="commsids">IP Services: Understand and prepare for expanded Intrusion
Detection Services</h3>
<p><strong>Description:</strong> Beginning in z/OS V1R13, Intrusion Detection Services (IDS) is
enhanced to monitor IPv6 traffic. This includes scan detection and
reporting, attack detection, attack reporting, attack prevention,
and traffic regulation.  Additional attack detection, reporting, and
prevention are also provided for IPv4 traffic.</p><a id="idx414"></a><a id="idx415"></a><a id="idx416"></a><a id="idx417"></a>
<table id="wq286" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installating z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using IDS on a stack that is
being run as a dual-mode stack (IPv4 and IPv6).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>If any of the following IDS attack types are enabled, be aware
that both IPv4 and IPv6 traffic will be monitored for attacks of these
types:
<ul>
<li>Malformed attack type</li>
<li>UDP perpetual echo attack type</li>
<li>Flood attack type</li>
<li>ICMP redirect attack type</li></ul></li>
<li>If you use the <span class="pk">trmdstat</span> command to get a consolidated
view of IDS log records, be aware that the default report, provided
when the <span class="pk">trmdstat</span> command is issued with no report option,
will be the IDS Summary report.  The IDS Summary report provides a
summary of all IDS information.</li>
<li>If you have a TCP scan rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then TCP scan events will be detected for
both IPv4 and IPv6 packets. If you want the TCP scan rule to continue
to only detect scan events for IPv4 packets, modify the rule to specify
a local IP address of 0.0.0.0/0.</li>
<li>If you have a UDP scan rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then UDP scan events will be detected for
both IPv4 and IPv6 packets.  If you want the UDP scan rule to continue
to only detect scan events for IPv4 packets, modify the rule to specify
a local IP address of 0.0.0.0/0.</li>
<li>If you have a TCP traffic regulation (TR) rule that applies to
all local IP addresses (such as when the LocalHostAddr All is specified
explicitly or by default in the policy), then limits will be enforced
for both IPv4 and IPv6 connection requests.  If you want the TCP TR
rule to continue to only enforce limits for IPv4 connection requests,
modify the rule to specify a local IP address of 0.0.0.0/0.</li>
<li>If you have a UDP TR rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then limits will be enforced for both IPv4
and IPv6 packets.  If you want the UDP TR rule to continue to only
enforce limits for IPv4 packets, modify the rule to specify a local
IP address of 0.0.0.0/0.</li>
<li>If you use LDAP to configure IDS policy and you are using the
default value for attribute ibm-idsLocalHostIPAddress with a TCP scan,
UDP scan, TCP TR, or UDP TR rule, events will be detected and limits
will be enforced for both IPv4 and IPv6 traffic.  If you want these
rules to continue to apply to only IPv4 traffic, modify the attribute
to specify ibm-idsLocalHostIPAddress:3-0.0.0.0-0.</li></ol>
<p><strong>Reference information:</strong> For details, see the
following:</p>
<ul>
<li> <a href="&amp;releasenlx;.halz002/ids.htm">Intrusion Detection Services</a> in >z/OS Communications Server: IP Configuration Guide</a></li>
<li>IBM Configuration Assistant
for z/OS Communications Server
online help; see the What's New in V1R13 help information for IDS
configuration</li>
<li><a href="&amp;releasenlx;.halz001/poldef.htm">IDS
policies defined in IDS configuration files</a> in  >z/OS Communications Server: IP Configuration Reference</a></li></ul><a id="idx418"></a><a id="idx419"></a>
<h3 id="ftchkpwd">IP Services: Ensure that the FTP user exit routine FTCHKPWD
tolerates an additional parameter</h3>
<p><strong>Description:</strong> Starting in z/OS V1R13, the z/OS FTP
server is enhanced to allow logging into FTP with a password phrase.
An additional parameter describing the password or password phrase
that is used to log into the z/OS FTP
server is now passed to the FTCHKPWD user exit. <span>If you
have installed an FTCHKPWD exit routine, and your exit routine meets
one or both criteria listed in <strong>Is the migration action
required?</strong> below, then you must take action.</span></p><a id="idx420"></a><a id="idx421"></a><a id="idx422"></a><a id="idx423"></a>
<table id="wq288" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation uses the FTCHKPWD
user exit routine, and if one of the following conditions is true:
<ul>
<li>Your exit routine cannot tolerate an additional parameter passed
to the exit routine.</li>
<li>Your exit routine inspects or processes the password parameter
in any way.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Inspect your FTCHKPWD user exit routine.  Modify as needed to
support the additional parameter.</li></ul>
<p><strong>Reference information:</strong> For details, see the
following:</p>
<ul>
<li><a href="../com.ibm.zos.r13.halz002/pwduext.htm">The FTCHKPWD user exit</a> in >z/OS Communications Server: IP Configuration Guide</a>.</li>
<li><a href="../com.ibm.zos.r13.halz001/ftchkext.htm">The FTCHKPWD user exit</a> in >z/OS Communications Server: IP Configuration Reference</a>.</li></ul>
<h3 id="portrnge">IP Services: Understand change in VIPARANGE security
verification processing</h3>
<p><strong>Description:</strong> Prior to z/OS V1R13, the System Authorization
Facility (SAF) resource profile associated with the VIPARANGE statement
(EZB.BINDDVIPARANGE.<var class="pv">sysname</var>.<var class="pv">tcpname</var>) was ignored
in the following scenario when an application issues a bind: <a id="idx424"></a></p>
<ul>
<li>The port specified on the bind matches a PORT statement, and</li>
<li>the IP address of the application's bind is within a VIPARANGE
subnet, or the application's bind is an unspecified address and the
IP address on the BIND parameter of the PORT statement is within a
VIPARANGE subnet.</li></ul>
<p>In this scenario, the PORT statement (including its optional SAF
parameter) was used to control access to both the port and to creating
the dynamic VIPA (DVIPA).</p>
<p>Beginning in V1R13, the VIPARANGE resource profile is
not ignored in this scenario; creation of the IP address is controlled
by both the SAF resource profile associated with the VIPARANGE statement
and by the PORT statement:</p>
<ul>
<li>For a VIPARANGE statement, you can control the creation of the
IP address by defining the following SAF resource profiles in the
SERVAUTH class:
<ul>
<li>EZB.BINDDVIPARANGE.<var class="pv">sysname</var>.<var class="pv">tcpname</var></li>
<li>EZB.BINDDVIPARANGE.<var class="pv">sysname</var>.<var class="pv">tcpname</var>.<var class="pv">resname</var>,
if the new SAF parameter is included on the VIPARANGE statement</li></ul></li>
<li>The PORT statement controls whether an application can
bind to a given port.</li></ul>
<table id="wq289" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have defined the EZB.BINDDVIPARANGE.<var class="pv">sysname</var>.<var class="pv">tcpname</var> resource
profile, but you have not given READ access to this resource to all
applications that create DVIPAs by binding to addresses that are within
a VIPARANGE subnet.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Be aware that the
EZB.BINDDVIPARANGE.<var class="pv">sysname.tcpname</var> resource profile is always
checked if defined; ensure all applications that create DVIPAs by
binding to addresses within a VIPARANGE subnet have READ access to
this resource.</p>
<p><strong>Reference information:</strong> For details, see the
following:</p>
<ul>
<li><a href="../com.ibm.zos.r13.halg001/rdsysdvp.htm">Enhanced
security for binding to DVIPAs</a> in >&amp;halg001t;</a></li>
<li><a href="../com.ibm.zos.r13.halz002/dracfmod.htm">Defining a security profile for SIOCSVIPA, SIOCSVIPA6,
and MODDVIPA</a> in >&amp;halz002t;</a></li>
<li><a href="../com.ibm.zos.r13.halz002/drpvr.htm">Defining a security profile for
binding to DVIPAs in the VIPARANGE statement</a> in >&amp;halz002t;</a></li>
<li><a href="../com.ibm.zos.r13.halz001/vparang.htm">VIPARANGE statement</a> in >z/OS Communications Server: IP Configuration Reference</a></li></ul>
<h3 id="ipfrags">IP Services: Update IP filter policy to filter IP fragments
correctly for RFC 4301 compliance</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R12, all IP security filters must be compliant
with RFC 4301. You can no longer use the RFC4301Compliance parameter
on the IpFilterPolicy statement to specify whether Policy Agent enforces
compliance. The RFC4301Compliance parameter is ignored and Policy
Agent enforces the rule that ensures all IP filters are compliant.</p>
<p>IP filter policy support for filtering fragments was improved in z/OS V1R10. Before z/OS V1R10, Communications Server
filtered all IP fragments using a policy of first possible filter
match and filtered IPv6 fragments as protocol IPv6Frag. Beginning
with z/OS V1R10, Communications
Server follows rules and restrictions established by RFC 4301 (<a href="http://www.ietf.org/rfc/rfc4301.txt">http://www.ietf.org/rfc/rfc4301.txt</a>) to ensure
proper classification of fragments. RFC 4301, &quot;Security Architecture
for the Internet Protocol&quot;, specifies the base architecture for
IPSec-compliant systems, including restrictions on the routing of
fragmented packets.</p>
<p>Communications Server does not implement stateful fragment checking,
therefore, restrictions were added as required by RFC 4301 to require
that IP filter rules for routed traffic do not allow specific ports,
types, or codes. The configuration parameter RFC4301Compliance could
be used in z/OS V1R10 and z/OS V1R11 to optionally configure
whether the RFC 4301 rules should be applied. Beginning with z/OS V1R12, this parameter (RFC4301Compliance
on the IpFilterPolicy statement) is deprecated. All IP filter rules
must support the RFC 4301 rules and restrictions.</p><a id="idx425"></a><a id="idx426"></a><a id="idx427"></a><a id="idx428"></a><a id="idx429"></a>
<table id="wq290" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your IP filter policy selectively matches
routed traffic based on TCP port, UDP port, ICMP type and code, ICMPv6
type and code, OSPF type, or MIPv6 type. If you configured the RFC4301Compliance
parameter on the IpFilterPolicy statement, it is recommended that
you remove the parameter because it is deprecated beginning with z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use IBM Health
Checker for z/OS check ZOSMIGV1R11_CS_RFC4301
to determine if IPSec filter rules are compliant with RFC4301.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you currently use the IBM Configuration Assistant for z/OS Communications Server to configure
your IP security policy, perform the following steps: </p>
<ul>
<li>If each configured TCP/IP stack has the RFC 4301 setting marked
compliant, no migration action is required. By default, the RFC 4301
setting is marked compliant.</li>
<li>Otherwise, for each stack with the RFC 4301 setting marked not
compliant:
<ol type="1">
<li>Change the setting to compliant. Click Apply Changes and a report
will be displayed.</li>
<li>Study the report. The report indicates if any rules were detected
that are not RFC 4301 compliant, and it explains the reasons why.</li>
<li>If the report indicates a user action is required, go to each
rule marked as incomplete, select the rule, and click the View Details
button to determine the user action required. Edit each rule to make
the correction.</li></ol></li></ul>
<p>If you manually configure your IP security policy, use Policy Agent
to identify any IP security filter rules that are not compliant with
RFC 4301. </p>
<ul>
<li>If you have implemented the RFC4301Compliance parameter on the
IpFilterPolicy statement with a setting of Yes in your current release,
no migration action is required. You may optionally remove the parameter
because it is deprecated in V1R12. Beginning with V1R12, Policy Agent
will log a warning message if the RFC4301Compliance parameter is configured.
Policy Agent will enforce that all IP security rules are compliant
with RFC 4301.</li>
<li>Otherwise (you have not implemented the RFC4301Compliance parameter
with a setting of Yes in your current release), review your Policy
Agent log file to determine if there are any configured rules that
are not compliant with RFC 4301. Policy Agent will identify any filter
rules that are not compliant with RFC 4301 as warnings in release
V1R11.
<ol type="1">
<li>If Policy Agent does not identify any filter rules that are not
compliant with RFC 4301, no migration action is required.</li>
<li>If Policy Agent identifies filter rules that are not compliant
with RFC 4301, perform the following steps to ensure that all IpFilterRule
objects pertaining to routed traffic do not distinguish between port,
type, or code values. For this process, identify all IpFilterRule
objects that pertain to routed traffic (for example, objects that
have an IpService Routing specification of Routed or Either). For
each of these IpFilterRule objects, perform the following steps: 
<ol type="a">
<li>If the IpService Routing specification is Either but the filter
rule applies only to local traffic, correct the Routing specification
to read Local.</li>
<li>If the IpService Routing specification is Routed and the filter
rule applies to certain specific ports, types, or codes, perform the
following steps: 
<ol type="i">
<li>Identify all IpFilterRule objects that apply to routed traffic
between the same or overlapping endpoints as the IpFilterRule under
consideration.</li>
<li>z/OS V1R12 Communications
Server requires that the same filter policy action be applied to all
ports, types, or codes between the same routed endpoints. This is
necessary because of the inherent ambiguity in determining the correct
policy action to take for fragments in which these values are unknown.
At your choice, you may apply the same policy action to a single IP
protocol or to all IP protocols between the same routed endpoints.
Consult the filter rules identified in the previous step and choose
an appropriate filter action of deny, permit, or ipsec to be applied
to all of this traffic. If you choose an action of ipsec, choose an
appropriate level of IPSec protection for all of this traffic.</li>
<li>Create a single IpFilterRule for the traffic identified in the
previous step pertaining to all port, type, or code values or to all
protocols, at your choice and with the filter action of your choice.</li>
<li>Remove all port-, type-, and code-specific IpFilterRule objects
that were previously identified as pertaining to routed traffic between
the same pair of endpoints as the IpFilterRule under consideration.</li>
<li>Change the policy at the corresponding security endpoint to match
the changes made to local policy.</li>
<li>For this routed traffic, enforce sufficient IP filter policy at
the final IP traffic destination node to ensure that unwanted traffic
is denied based on the port-, type-, or code-specific IpFilterRule
objects that were previously removed from the local policy.</li></ol></li>
<li>If the IpService Routing specification is Either and the filter
rule applies to certain specific ports, types, or codes, perform the
following steps: 
<ol type="i">
<li>Create two copies of this filter rule, one of which has a Routing
specification of Local and one of which has a Routing specification
of Routed.</li>
<li>Leave the Local filter rule unchanged; for the Routed filter rule,
perform the steps listed in 2b to apply new routed traffic restrictions.</li></ol></li>
<li>Otherwise, no change is necessary for this IpFilterRule.</li></ol></li></ol></li></ul>
<p><strong>Reference information:  </strong> </p>
<ul>
<li>&quot;<a href="../com.ibm.zos.r13.halz001/secserv.htm">IpService statement</a>&quot; in >z/OS Communications Server: IP Configuration Reference</a></li></ul>
<h3 id="snmpsys">IP Services: Remove customization of SNMP sysObjectID MIB object
in OSNMPD.DATA file</h3>
<p><strong>Description:</strong> The SNMP agent allows you to
provide some initial settings for a small set of MIB objects by using
the OSNMPD.DATA file. One of the objects for which an initial value
can be provided is sysObjectID.0. The sysObjectID.0 object is the
vendor's authoritative identification of the network management subsystem
contained in the entity. That is, it is intended to uniquely identify
the SNMP agent. Changing this value is not recommended and the ability
to change it will be disabled in a future release. As of z/OS V1R4, warning message EZZ6317I
is written to the syslog daemon if the object is set by using the
OSNMPD.DATA file. As of z/OS V1R8,
message EZZ6317I is also written to the console.</p><a id="idx430"></a><a id="idx431"></a><a id="idx432"></a><a id="idx433"></a>
<table id="wq296" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>Future removal of the ability to customize the
sysObjectID value was announced in the z/OS V1R4
time frame. Message EZZ6317I is written to the syslog daemon as of z/OS V1R4, and to both the syslog
daemon and console as of z/OS V1R8.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the ability to customize
the sysObjectID value is planned to be removed in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review the statements in your
OSNMPD.DATA configuration file. If this file contains a statement
for the sysObjectID object, remove the statement from the file.</p>
<p><strong>Reference information:</strong> For details about
statements in the OSNMPD.DATA configuration file, see the network
management topic of >z/OS Communications Server: IP Configuration Guide</a>.</p>
<h3 id="ressolv">IP Services: Restore resolver UDP request timeout interval
duration</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, the default setting for considering
UDP requests to a name server to have timed out (as specified by the
TCPIP.DATA RESOLVERTIMEOUT statement) was 30 seconds. Starting with z/OS V1R12, the default is 5 seconds.
If you want the resolver to continue to use the old value, you must
take action.</p><a id="idx434"></a><a id="idx435"></a><a id="idx436"></a><a id="idx437"></a>
<table id="wq297" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your network requires longer than 5
seconds for resolver queries to be processed by a name server under
normal network conditions.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Code the RESOLVERTIMEOUT 30 statement in each TCPIP.DATA dataset
where the previous UDP timeout duration interval is needed.</li>
<li>If the resolver is active when all the TCPIP.DATA datasets are
updated, issue the MODIFY <em>resolver</em>,REFRESH
command to cause the resolver to refresh the TCPIP.DATA settings.</li>
<li>If the resolver is not active, start the resolver.</li></ul>
<p><strong>Reference information:</strong></p>
<ul>
<li><a href="&amp;releasenlx;.halz001/opento.htm">RESOLVERTIMEOUT statement</a> in >&amp;halz001t;</a></li>
<li><a href="&amp;releasenlx;.halu101/resolvecmd.htm">MODIFY command: Resolver
address space</a> in >&amp;halu101t;</a></li></ul>
<h3 id="addrinf">IP Services: Ensure applications tolerate a larger addrinfo
structure</h3>
<p><strong>Description:</strong> The addrinfo structure is used
by the getaddrinfo() function to hold host address information. In z/OS V1R12, the addrinfo structure
(struct addrinfo) is enhanced to comply with RFC 5014.   As a result,
the struct addrinfo is larger than it was prior to z/OS V1R12. When the res parameter returned by getaddrinfo()
is a chain of pointers to struct addrinfo structures, the pointers
point to the larger struct addrinfo.</p><a id="idx438"></a><a id="idx439"></a><a id="idx440"></a>
<table id="wq298" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because your application might have a dependency
on the size of the struct addrinfo structures returned by the getaddrinfo()
subroutine points.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Be aware that the res parameter returned by the getaddrinfo()
subroutine will point to larger struct addrinfo structures.</li>
<li>Change your application as necessary to accommodate larger struct
addrinfo structures.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS XL C/C++ Run-Time Library Reference</a></li>
<li>>z/OS UNIX System Services Programming: Assembler Callable Services Reference</a></li></ul>
<h3 id="restask">IP Services: Release addrinfo storage after resolver thread
task terminates</h3>
<p><strong>Description:</strong> The resolver allocates storage
in the application address space to contain the addrinfo data returned
by the getaddrinfo() function. Prior to z/OS V1R12,
the resolver released this storage when the task that issued the getaddrinfo()
function terminated. With z/OS V1R12,
the resolver releases the addrinfo storage when the process task that
owns the task that issued the getaddrinfo() function terminates. Applications
with long-running tasks that do not explicitly release addrinfo storage
using the freeaddrinfo() function might experience an increase in
storage usage.</p><a id="idx441"></a><a id="idx442"></a><a id="idx443"></a>
<table id="wq299" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to prevent excessive consumption
of application virtual storage by resolver functions.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update application source
code to ensure that the freeaddrinfo() function is issued to release
all addrinfo storage obtained using the getaddrinfo() function.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li> Protocol-independent nodename and service name translation in >z/OS Communications Server: IPv6 Network and Application Design Guide</a>.</li>
<li> <a href="&amp;releasenlx;.hala001/creix.htm">FREEADDRINFO</a> for the macro
API in >&amp;hala001t;</a>.</li>
<li> <a href="&amp;releasenlx;.hala001/getadd.htm">GETADDRINFO</a> for the macro
API in >&amp;hala001t;</a>.</li>
<li><a href="&amp;releasenlx;.hala001/creix1.htm">FREEADDRINFO</a> for the CALL
instruction API in >&amp;hala001t;</a>.</li>
<li><a href="&amp;releasenlx;.hala001/getadd.htm">GETADDRINFO</a> for the CALL instruction
API in >&amp;hala001t;</a>.</li>
<li>>z/OS Communications Server: IP IMS Sockets Guide</a>.</li></ul>
<h3 id="syslogup">IP Services: Update syslogd configuration for archiving rules
with shared z/OS UNIX file destinations</h3>
<p><strong>Description:</strong> Starting with z/OS V1R11, you can configure the syslogd daemon
(syslogd) to perform automatic archiving for z/OS UNIX files.
 You do this by specifying the -N parameter on the appropriate syslogd
rules in the configuration file, along with specific configuration
statements for the archive function.  Beginning with z/OS V1R12, if you use the same z/OS UNIX file
destination on multiple syslogd rules, the automatic archiving function
is not supported on any of these rules.</p><a id="idx444"></a><a id="idx445"></a>
<table id="wq300" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you configure multiple syslogd rules
that use the same z/OS UNIX file destination, and if you
configure automatic archiving for that destination file.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you configure multiple
syslogd rules that use the same z/OS UNIX file destination, and configure
automatic archiving for that destination file, perform the following
steps: </p>
<ul>
<li>If you do not require automatic archiving, remove the -N parameter
from all rules that share the same z/OS UNIX file destination.</li>
<li>If you do require automatic archiving, change the destination
to a unique z/OS UNIX file for each rule that shares
the same z/OS UNIX file destination.</li></ul>
<div>
<div class="notetitle" id="wq301">Note:</div>
<div class="notebody">If you do not perform either of these steps,
message FSUM1273 <var class="pv">jobname</var> AUTOMATIC ARCHIVE NOT USED FOR RULES
WITH SHARED DESTINATION is issued to the operator console, and one
or more instances of message FSUM1272 WARNING: ARCHIVE FUNCTION DISABLED
FOR RULES WITH SHARED DESTINATION <var class="pv">filename</var> is written to
the syslogd error destination. The automatic archiving function is
turned off for all syslogd rules that share z/OS UNIX file
destinations. Although automatic archiving is turned off, syslogd
continues to log messages to the destination file.</div></div>
<p><strong>Reference information:</strong> For more information,
see syslog daemon in >z/OS Communications Server: IP Configuration Reference</a>.</p>
<h3 id="asgnbuf">SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests
do not exceed 500 images for a single CSM buffer</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R13, Communications Storage
Manager (CSM) will reject the ASSIGN_BUFFER request after 500 image
buffers of a single CSM buffer are requested, and CSM will return
a new reason code of 26.<span> The new reason code 26 states: &quot;Assign
buffer request failed because CSM reached the limit of the maximum
number of image buffers of the single CSM buffer.&quot;</span></p><a id="idx446"></a><a id="idx447"></a><a id="idx448"></a><a id="idx449"></a>
<table id="wq302" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended. Your application probably
does not request more than 500 images of a CSM buffer; however, you
should examine IVTCSM ASSIGN_BUFFER calls to ensure that this is the
case.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> <span>To prevent application
failures because of excessive ASSIGN_BUFFER requests:</span></p>
<ul>
<li>Identify any authorized applications that use CSM services and
verify that the number of image buffers requested by IVTCSM ASSIGN_BUFFER
for a single CSM buffer can never be more than 500.</li>
<li>If necessary, change the application so the total number
of IVTCSM ASSIGN_BUFFER image buffer requests is 500 or less.</li></ul>
<p><strong>Reference information:</strong> None.</p>
<h3 id="vtamsgt">SNA Services: Ensure VTAMSG2 in not used in your VTAMLST definitions</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, VTAMSG2 is a new reserved name of an
internal major node built by VTAM.
 As such, there should be no other use of the name VTAMSG2 in the VTAM definitions that are used
by your system.<a id="idx450"></a></p>
<table id="wq303" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have used the name VTAMSG2 in any
of your VTAM definition statements.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Investigate all your VTAM definitions.</li>
<li>If you find the name VTAMSG2 in any of them, change the name to
a non-reserved name. Note that if you continue to configure and
try to activate VTAMSG2, message IST607I VARY ACT FOR VTAMSG2 FAILED
- INVALID NODE TYPE OR STATE will be issued.</li></ol>
<p><strong>Reference information:</strong> For details about
your VTAM definitions, see <a href="&amp;releasenlx;.istimp0/ravvtxo.htm">Resources automatically activated
by VTAM</a> in >z/OS Communications Server: SNA Network Implementation Guide</a>.</p>
<h2 id="wq305">Communications Server actions to perform before the first IPL
of z/OS V1R13</h2>
<p>This topic describes Communications Server migration actions that
you can perform after you have installed z/OS V1R13 but before the first time you IPL. These
actions might require the z/OS V1R13
level of code to be installed but do not require it to be active.</p>
<h3 id="tcpip">IP and SNA Services: Remove TCPIPDS1 and ISTITDS1 specification
from dump commands</h3>
<p><strong>Description:</strong> z/OS V1R13
Communications Server relocates trace records in the TCP/IP data space
TCPIPDS1 and in the VTAM data
space ISTITDS1 to 64-bit common (HVCOMMON) storage. Beginning with
V1R13, you should not include these data spaces when you dump the
TCP/IP stack or VTAM data space.<a id="idx451"></a></p>
<table id="wq306" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td width="36%"><strong>Element or feature:</strong></td>
<td width="63%">Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you issue commands to dump TCP/IP including
the TCPIPDS1 dataspace, or VTAM including
the ISTITDS1 dataspace and do not want to receive the message ASA104I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to remove the DSPNAME for the non-existent
data spaces continues with a dump taken as normal and with message
ASA104I: 
<pre class="xmp"><code>R 5,DSPNAME=('TCPCS'.TCPIPDS1,'OMVS'.*),CONT                      
IEE600I REPLY TO 05 IS;DSPNAME=('TCPCS'.TCPIPDS1,
'OMVS'.*),CONT  
ASA104I SYNTAX ERROR IN POSITION 18. 288                         
ERROR IN VALUE FOR KEYWORD DSPNAME -                             
NO MATCH FOUND.                                                  
DETECTING MODULE IS IEAVTS0A                                     
*06 IEE094D SPECIFY OPERAND(S) FOR DUMP COMMAND </code></pre>     Because FFST&trade; dumps do not include data spaces,
they are are  not affected.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Check for dump commands that use DSPNAME=('TCPIP'.*) or DSPNAME=('TCPIP'.TCPIPDS1)
and remove the DSPNAME parameter.</li>
<li>Check for dump commands that use DSPNAME=('VTAM'.ISTITDS1) and
remove the DSPNAME parameter. Note that VTAM uses
additional data spaces, so you should not remove any DSPNAME parameter
that specifies a wildcard data space name.</li></ol>
<p><strong>Reference information:</strong> For details, see the
following:</p>
<ul>
<li>Topic "Obtaining component trace data with a dump." in <cite></cite>>&amp;halz001t;</a></li></ul>
<h3 id="viparange">IP Services: Review VIPARANGE definitions</h3><a id="idx452"></a><a id="idx453"></a><a id="idx454"></a><a id="idx455"></a><a id="idx456"></a><a id="idx457"></a>
<p><strong>Description:</strong> Prior to z/OS V1R13, for any dynamic VIPA (DVIPA) creation
request, the first matching VIPARANGE statement is used when creating
a DVIPA. Beginning in z/OS V1R13,
the most specific VIPARANGE statement match is used when creating
a DVIPA.<a id="idx458"></a></p>
<table id="wq308" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure DVIPAs are created
as intended.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Be aware of the change in VIPARANGE processing.</li>
<li>Update VIPARANGE definitions as needed.</li></ol>
<p><strong>Reference information:</strong> For details, see the
following:</p>
<ul>
<li><a href="../com.ibm.zos.r13.halz001/vparang.htm">VIPARANGE statement</a> in >&amp;halz001t;</a></li></ul>
<h3 id="tn3720e">IP Services: Update automation that keys on TN3270E Telnet
server messages</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, all Telnet messages began with the word
"TELNET" after the message identifier. The DEBUG, LUNS, and LUNR messages
began with "TELNET <em>jobname</em>" after the message
identifier.  Starting with z/OS V1R12,
the first word "TELNET" is replaced with the jobname.  For the DEBUG,
LUNS, and LUNR messages, all other words in the message are shifted
to the left.  If you have automation which assumes certain positions
for these messages, you must make accommodations to accept the new
format of these messages.  <a id="idx459"></a></p>
<table id="wq310" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation checking Telnet
server messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure that no automation
expects the first word of a Telnet message to be "TELNET" and ensure
that any automation that keys on the DEBUG message EZZ6035I, or the
LUNS and LUNR messages EZZ6091I - EZZ6099I, is updated to handle the
word shift to the left.</p>
<p><strong>Reference information:</strong> For details about
the TN3270E Telnet messages and jobnames, see <a href="&amp;releasenlx;.halb101/chpt6.htm">EZZ6<em>xxxx</em> messages</a> in >z/OS Communications Server: IP Messages Volume 4 (EZZ, SNM)</a>.</p>
<h3 id="telsrvr">IP Services: Ensure the TN3270E Telnet server can end automatically
when an OMVS shutdown command is issued</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, if the Telnet application was active
when you issued the F OMVS,SHUTDOWN command, Telnet continued to be
active but in an unusable state. Starting with z/OS V1R12, Telnet stops automatically when you
issue the F OMVS,SHUTDOWN command. Messages are issued in the
order they appear below:</p>
<pre class="xmp"><code>BPXI055I OMVS SHUTDOWN REQUEST ACCEPTED
EZZ6008I <var class="pv">tnproc</var> STOPPING
EZZ6010I <var class="pv">tnproc</var> SERVER ENDED FOR PORT 23
EZZ6009I <var class="pv">tnproc</var> SERVER STOPPED</code></pre>
<table id="wq311" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you issue an F OMVS,SHUTDOWN command
when the Telnet application is active.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review your procedures for
issuing the F OMVS,SHUTDOWN command and be aware the Telnet server
will stop when the command is issued.</p>
<p><strong>Reference information:</strong> See <a href="&amp;releasenlx;.halz002/mgrtel.htm">Managing
Telnet</a> in >z/OS Communications Server: IP Configuration Guide</a>.</p>
<h3 id="disreso">IP Services: Disable resolver monitoring of name server responsiveness</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, the z/OS Communications
Server system resolver did not provide notification of situations
where a Domain Name System (DNS) name server was not responding to
resolver queries sent to the name server. Starting with z/OS V1R12, the resolver will notify
the operator when an unresponsive name server is detected. This function
provides critical diagnostic information to the network operator and
allows the operator to take steps to avoid performance and availability
problems. If you do not want the resolver to provide these notifications,
you must take action.</p><a id="idx460"></a><a id="idx461"></a>
<table id="wq312" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want notification of potential
problems with name servers in your network.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you do not already have a resolver setup file, create one.</li>
<li>Code the UNRESPONSIVETHRESHOLD(0) statement in a resolver setup
file. A <var class="pv">percentage_of_queries</var> value of 0 indicates that resolver
should not monitor name server responsiveness. The default percentage
is 25% of resolver queries.</li>
<li>If resolver is active, issue the MODIFY <em>resolver</em>,REFRESH,SETUP=<em>resolver_setup_file</em> command to cause the resolver
to stop monitoring name server responsiveness.</li>
<li>If the resolver is not active, start the resolver.</li></ul>
<p><strong>Reference information:</strong></p>
<ul>
<li><a href="&amp;releasenlx;.halz002/ressetup.htm">Steps for creating
a resolver setup file</a> in >&amp;halz002t;</a></li>
<li><a href="&amp;releasenlx;.halz002/dnsresponse.htm">Monitoring the responsiveness of Domain Name System
name servers</a> in >&amp;halz002t;</a></li>
<li><a href="&amp;releasenlx;.halz001/notrehold.htm">UNRESPONSIVETHRESHOLD
statement</a> in  >&amp;halz001t;</a></li>
<li><a href="&amp;releasenlx;.halu101/resolvecmd.htm">MODIFY command: Resolver
address space</a> in >&amp;halu101t;</a></li></ul>
<h3 id="dynavpm">IP Services: Disable IP validation checks when defining key
exchange policy rules for a dynamic VPN</h3>
<p><strong>Description:</strong> You can configure policy rules
for IP security when defining key exchange policy for dynamic virtual
private networks (DVPNs).  Prior to z/OS V1R12,
there was no automatic way to verify that the identity of the remote
peer matched the IP address of the remote peer. Beginning with z/OS V1R12, such IP validation
checks are enforced by default. If you do not want the IP validation
checking enabled on your policy rules for security key exchanges,
you must disable it.</p>
<p></p>
<div>
<div class="notelisttitle" id="wq313">Notes:</div>
<ol type="1">
<li>The new default to enable IP validation checking is a benefit;
however, one example of why you might want to disable the checking
is if your remote security endpoint is expected to be behind a network
address translation (NAT) device.</li>
<li>A value coded on the parameter to disable the automatic IP validation
checking is ignored if the identity of the peer is not an IPv4 or
IPv6 address.</li>
</ol></div><a id="idx462"></a><a id="idx463"></a><a id="idx464"></a><a id="idx465"></a><a id="idx466"></a><a id="idx467"></a><a id="idx468"></a>
<table id="wq315" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want bypass the IP security key
exchange validation check that verifies that the identity of the remote
peer matches the IP address of the remote peer.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Specify the value YES on the
BypassIpValidation parameter of the KeyExchangePolicy or KeyExchangeAction
statements.  (The value of NO is the default).</p>
<p><strong>Reference information:</strong> For details, see the <a href="&amp;releasenlx;.halz001/secact.htm">KeyExchangeAction</a> and <a href="&amp;releasenlx;.halz001/seckeyex.htm">KeyExchangePolicy</a> statements
in .</p>
<h3 id="modnets">IP Services: Update modified Netstat message catalogs to include
timestamp</h3>
<p><strong>Description:</strong> z/OS V1R12
enhances Netstat to verify that its message catalogs are at the same
maintenance level as the Netstat program.  If the message catalog
time stamp does not match the Netstat program time stamp, Netstat
uses the default messages.  If you are customizing the netmsg.cat
or netmsg6.cat message catalogs, you must take action to preserve
the time stamp.</p><a id="idx469"></a><a id="idx470"></a><a id="idx471"></a>
<table id="wq316" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are customizing either the netmsg.cat
or netmsg6.cat message catalog.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Issue the <strong>dspcat</strong> command with the -t -g
options against the netmsg.cat (for example, issue <strong>dspcat
netmsg.cat -g -t</strong>) to retrieve the necessary output to supply
to the <strong>gencat</strong> command to generate your translated
message catalog. The z/OS Communications
Server netmsg.cat is installed in the z/OS UNIX file system directory /usr/lpp/tcpip/lib/nls/msg/C.
<p>The
output file displays as follows:</p>
<pre class="xmp"><code>The time stamp of catalog netmsg.cat is: 2009 112 00:11 UTC
$delset 1
$set 1
$quote "</code></pre></li>
<li>Remove the first line of the output file generated by the <strong>dspcat</strong> command and replace it with a $timestamp
directive and the time stamp value from the same output file.
<p>The
new output file displays as follows:</p>
<pre class="xmp"><code>$timestamp   2009 112 00:11 UTC
$delset 1
$set 1
$quote "</code></pre></li>
<li>Make any other appropriate changes to customize your message catalog
 and issue the <strong>gencat</strong> command to generate the
new message catalog.</li>
<li> Repeat steps 1-3 for the netmsg6.cat message catalog.</li></ol>
<p><strong>Reference information:</strong> For additional information
on customizing message catalogs, see <a href="&amp;releasenlx;.halz002/custimgs.htm">Customize
TCP/IP messages</a> in >z/OS Communications Server: IP Configuration Guide</a>.</p>
<h3 id="upcsetc">IP Services: Update /etc configuration files</h3>
<p><strong>Description:</strong> Some utilities provided by Communications
Server require the use of certain configuration files. You are responsible
for providing these files if you expect to use the utilities. IBM provides default configuration
files as samples in the <samp class="xph">/usr/lpp/tcpip/samples</samp> directory.
Before the first use of any of these utilities, you should copy these
IBM-provided samples to the <samp class="xph">/etc</samp> directory (in most cases).
You can further customize these files to include installation-dependent
information. An example is setting up the <samp class="xph">/etc/osnmpd.data</samp> file
by copying the sample file from <samp class="xph">/usr/lpp/tcpip/samples/osnmpd.data</samp> to <samp class="xph">/etc/osnmpd.data</samp> and
then customizing it for the installation.</p>
<p>If you customized any of the configuration files that have changed,
then you must incorporate the customization into the new versions
of the configuration files.</p>
<table id="wq318" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>Various releases. See <a href="#csetctb">Table 9</a>.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have customized a configuration
file (listed in <a href="#csetctb">Table 9</a>) that IBM has changed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong>  If you added installation-dependent
customization to any of the IBM-provided configuration files listed
in <a href="#csetctb">Table 9</a>, make the same changes in the new versions
of the files by copying the IBM-provided samples to the files shown
in the table and then customizing the files.</p>
<table id="csetctb" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 9. Changed Communications Server configuration files</caption>
<thead valign="bottom">
<tr>
<th id="wq319" width="19%" align="left" valign="bottom">Utility</th>
<th id="wq320" width="34%" align="left" valign="bottom">IBM-provided sample file</th>
<th id="wq321" width="19%" align="left" valign="bottom">Target location</th>
<th id="wq322" width="26%" align="left" valign="bottom">What changed and when</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top" headers="wq319">Internet Key Exchange Daemon (IKED)</td>
<td align="left" valign="top" headers="wq320">/usr/lpp/tcpip/samples/iked.conf</td>
<td align="left" valign="top" headers="wq321">/etc/security/iked.conf</td>
<td align="left" valign="top" headers="wq322">In z/OS V1R12,
a new configuration statement is provided to enable FIPS 140 mode
for the IKE daemon.</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq319">Network Security Services Server
Daemon (NSSD)</td>
<td align="left" valign="top" headers="wq320">/usr/lpp/tcpip/samples/nssd.conf</td>
<td align="left" valign="top" headers="wq321">/etc/security/nssd.conf</td>
<td align="left" valign="top" headers="wq322">In z/OS V1R12,
new configuration statements are provided to configure new functions
of the IPSec discipline, including FIPS 140 mode and HTTP retrieval
and caching of certificates, certificate bundles, and certificate
revocation lists.</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq319">Policy Agent</td>
<td align="left" valign="top" headers="wq320">/usr/lpp/tcpip/samples/pagent_CommonIPSec.conf</td>
<td align="left" valign="top" headers="wq321">N/A</td>
<td align="left" valign="top" headers="wq322">In z/OS V1R12,
new IPSec configuration options enable the use of IKEv2, and of new
cryptographic algorithms for IPSec traffic.</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq319">Policy Agent</td>
<td align="left" valign="top" headers="wq320">/usr/lpp/tcpip/samples/pagent.conf</td>
<td align="left" valign="top" headers="wq321">/etc/pagent.conf</td>
<td align="left" valign="top" headers="wq322">In z/OS V1R12,
the RFC4301Compliance parameter is deprecated on the IpFilterPolicy
statement.</td>
</tr>
<tr>
<td align="left" valign="top" headers="wq319">SNMP agent</td>
<td align="left" valign="top" headers="wq320">/usr/lpp/tcpip/samples/osnmpd.data</td>
<td align="left" valign="top" headers="wq321">/etc/osnmpd.data</td>
<td align="left" valign="top" headers="wq322">Every release, the value of the sysName
MIB object is updated to the current release.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more details about configuration files, see >z/OS Communications Server: IP Configuration Guide</a>.</li>
<li>For information about modifying the NFS samples, see Chapter 10
in >z/OS Network File System Guide and Reference</a>.</li></ul>
<h3 id="vitrelocate">SNA Services: Adjust to the relocation of the VTAM internal trace table</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, the VTAM internal
trace (VIT) table is relocated from ECSA to HVCOMMON and the VIT data
space is eliminated. As a result, be aware of the following changes
starting in z/OS V1R13:</p>
<ul>
<li>The SIZE parameter of the TRACE start option and the MODIFY TRACE
command is used to set the size of the VTAM Internal
Trace (VIT) table. Prior to z/OS V1R13,
the value of the SIZE parameter specified the number of pages of ECSA
(for example, SIZE=999). Starting with z/OS V1R13,
the value of the SIZE parameter of the TRACE start option and the
MODIFY TRACE command specifies the number of megabytes of HVCOMMON
(for example, SIZE=4M).</li>
<li>Starting with z/OS V1R13,
the DSPSIZE parameter is not valid. 
<ul>
<li>The DSPSIZE parameter was used to set the size of the VIT data
space. Prior to z/OS V1R13,
the value of the DSPSIZE parameter specified the number of megabytes
of data space in 10 megabytes increments (for example, DSPSIZE=5 for
50 megabytes).</li>
<li>If DSPSIZE is coded in the VTAM start
list, the following informational message is displayed: IST448I DSPSIZE
OPTION IGNORED - NO LONGER SUPPORTED. Processing then continues disregarding
the specification.</li>
<li>If DSPSIZE is specified on a MODIFY TRACE command, the following
informational message is displayed: IST448I DSPSIZE OPTION IGNORED
- NO LONGER SUPPORTED. The entire MODIFY TRACE command is ignored.
When you apply the VTAM APAR
OA39214, the message will be changed as follows. IST2365I MODIFY TRACE
COMMAND REJECTED - DSPSIZE NO LONGER SUPPORTED.</li></ul></li>
<li>Numerous messages are no longer issued and are retired.</li></ul><a id="idx472"></a><a id="idx473"></a><a id="idx474"></a>
<table id="wq323" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if one or more of the following conditions
are true:
<ul>
<li> If automation of the MODIFY TRACE command exists and the command
specifies SIZE in pages or DSPSIZE, and the failure of that command
is unacceptable.</li>
<li>If automated applications that parse retired messages not finding
any of the newly retired messages is unacceptable.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>
<ul>
<li>Valid SIZE values are 4M-2048M inclusive.</li>
<li>If you specify a SIZE value that is larger than the default value, z/OS will perform paging on portions
of the VIT table. Before you specify a large SIZE value, ensure that
you have sufficient real or auxiliary storage to contain the entire
VIT. Failure to ensure sufficient storage might result in an auxiliary
storage shortage. If an SVC dump is taken that includes common storage,
the size of the dump data set also increases. You must also take the
increase in the size of the dump data set into consideration.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Moving the VIT to HVCOMMON can make up to 999
pages of ECSA available to other applications or subsystems.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None. The VIT associated health checks have
been removed. See <a href="#uplochk">Update your check customization for modified IBM Health Checker for z/OS checks</a> for more information.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Migrate your VTAM start
lists:
<p>Although the VTAM internal
trace (VIT) table size is now specified in megabytes and the DSPSIZE
parameter is no longer valid, you are not forced to update your VTAM start lists before using z/OS V1R13. If you use a nonzero
DSPSIZE value in your start list, your tracing capacity will be diminished
unless you perform these migration tasks. You should convert your
SIZE value to megabytes and delete your DSPSIZE specification.</p></li>
<li>Migrate your automated MODIFY TRACE commands:
<p>Unlike the VTAM start lists, the migration
of any automation of the MODIFY TRACE command that specifies the value
of the SIZE parameter in pages or the DSPSIZE parameter is required
before using z/OS V1R13 if
the failure of that command is unacceptable. If you fail to perform
this migration effort, the automated command will be rejected, the
size of the table will remain unchanged, and any other modifications
specified on the command (for example, opt=all) will be ignored.</p></li>
<li>Migrate your TRACE option or MODIFY TRACE command when they specify
the SIZE parameter, the DSPSIZE parameter, or both parameters:
<ol type="1">
<li>If DSPSIZE=0 is specified, delete the specification. If the SIZE
parameter is also specified or you want a table size larger than 4
megabytes, proceed to steps 2, 3, and 4.</li>
<li>If DSPSIZE is not specified, specify the SIZE value as the number
of megabytes you want in your trace table (4 megabytes minimum, for
example, SIZE=4M). <span>Regardless of the size of the VIT,
only a few megabytes are backed by 64-bit real storage. This range
of fixed pages is dynamically shifted as VIT records are written.</span> The
migration task is complete for this start list or automated command.</li>
<li>If the DSPSIZE parameter is specified and the SIZE parameter is
not, change DSPSIZE to SIZE and change the value to the number of
megabytes you want in your trace table (4 megabytes minimum). If you
want to retain the equivalent of what was specified for DSPSIZE, specify
the SIZE value as the DSPSIZE value and append '0M'. For example,
DSPSIZE=1 is equivalent to SIZE=10M. The migration task is complete
for this start list or automated command.</li>
<li>If the DSPSIZE and SIZE parameters are both specified, delete
the DSPSIZE specification and change the value of the SIZE parameter
to the number of megabytes you want in your trace table (4 megabytes
minimum). If you want to retain the equivalent of what was specified
for the DSPSIZE parameter, change the value of the SIZE parameter
to the DSPSIZE value and append '0M'. For example, DSPSIZE=3 is
equivalent to SIZE=30M.</li></ol></li>
<li>Migrate applications that parse retired messages:
<p>If you have
automation that parses the output from the MODIFY TRACE, DISPLAY TRACE,
or DISPLAY STATS command, you might need to update them because the
VIT size is now reported in megabytes. Also, you will no longer see
DSPSIZE reported as the VIT data space has been removed.</p>
<p>In
addition, numerous messages are retired because they no longer apply.
As a result, perform the following steps:</p>
<ul>
<li>If you run automation that parses the output of the MODIFY or
DISPLAY TRACE command, change the automation to process megabytes
instead of pages.
<p>Previous message: <samp class="xph">IST315I  VTAM INTERNAL
TRACE ACTIVE - MODE = INT, SIZE = <span class="mv">size</span> PAGES</samp></p>
<p>Updated
message: <samp class="xph">IST315I  VTAM INTERNAL TRACE ACTIVE - MODE = INT, SIZE
= <span class="mv">size</span> MB</samp></p></li>
<li>If you run automation that parses the output of the DISPLAY STATS
command, change the automation to process megabytes instead of pages.
<p>Previous
message: <samp class="xph">IST1227I     2        999 = VIT TABLE SIZE</samp></p>
<p>Updated
message: <samp class="xph">IST1227I     2        4 = VIT TABLE SIZE</samp></p>
<p>Also,
you will no longer see the following message because the VIT data
space has been removed:</p>
<p><samp class="xph">IST1227I   163          0 = VIT
DATA SPACE TABLE SIZE</samp></p></li>
<li>If you run automation that parses any of the following messages,
delete the automation because the messages are either retired or no
longer used for the VIT.
<p><samp class="xph">IST318I VTAM INTERNAL TRACE ACTIVATION
FAILED -- UNABLE TO FIX STORAGE</samp></p>
<p><samp class="xph">IST495I <span class="mv">type</span> HAS
BEEN SET TO <span class="mv">value</span></samp></p>
<p><samp class="xph">IST1659I DATA SPACE <span class="mv">dspname</span> DSPSIZE
= <span class="mv">dspsize actsize</span></samp></p>
<p><samp class="xph">IST1741I DATA SPACE
SDUMPX FAILED WITH RETURN CODE <span class="mv">code</span> REASON <span class="mv">reason</span></samp></p>
<p><samp class="xph">ISTH003I
The VTAM Internal Trace (VIT) table size is at the maximum value,
which provides optimal trace information for problem determination</samp></p>
<p><samp class="xph">ISTH004E
VTAM Internal Trace (VIT) table size of vit_size is too small</samp></p>
<p><samp class="xph">ISTH007I
VTAM Internal Trace (VIT) dataspace size is at the maximum value,
which provides optimal trace information for problem determination</samp></p>
<p><samp class="xph">ISTH008E
VTAM Internal Trace (VIT) dataspace size of dspsize is too small</samp></p>
<p><samp class="xph">IVT5602I
DATA SPACE SDUMPX FAILED WITH RETURN CODE <span class="mv">code</span> REASON <span class="mv">reason</span></samp></p></li></ul></li>
<li>Other automation:
<p>If you have automation that parses for or
specifies the character string ISTITDS1, which prior to z/OS V1R13 was the name of
the data space containing the VIT data space, you might want to modify
that automation because the data space will no longer be created.
This is highly recommended if you have SLIP traps that dump the VIT
data space.</p></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>See <a href="../com.ibm.zos.r13.istrdr0/SOTRVI.htm">TRACE for MODULE, STATE
(with OPTION), or VTAM internal
trace</a> in >z/OS Communications Server: SNA Resource Definition Reference</a> for
additional information about specifying the size of the VTAM internal trace (VIT) table
using the VTAM TRACE start
option.</li>
<li>See <a href="../com.ibm.zos.r13.istopr0/FTR.htm">MODIFY TRACE command</a> in >z/OS Communications Server: SNA Operation</a> for
additional information about specifying the size of the VTAM internal trace (VIT) table
using the MODIFY TRACE command.</li></ul>
<h3 id="eeconnh">SNA Services: Disable Enterprise Extender connection health
verification</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, VTAM verifies
the health of the Enterprise Extender (EE) connection while the connection
is being activated. VTAM sends
a Logical Data Link Control (LDLC) probe to the remote partner using
all five ports during the activation. If the partner is not reachable
by any port for any reason, VTAM does
not start the EE connection. <span>VTAM issues the following health verification failure
message group if the attempt to connect failed during the activation
of the EE connection when VTAM sent
the LDLC probe to the remote partner:</span></p>
<pre class="xmp"><code>IST2330I EE HEALTH VERIFICATION FAILED FOR <var class="pv">puname</var> AT <var class="pv">time</var>
IST1680I <var class="pv">type</var> IP ADDRESS <var class="pv">ip_address</var>
IST1680I <var class="pv">type</var> IP ADDRESS <var class="pv">ip_address</var>
IST314I END</code></pre>
<p>If you do not want VTAM to
verify the health of the EE connection, code the start option EEVERIFY=NEVER
before starting VTAM.</p><a id="idx475"></a>
<table id="wq325" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you used fewer than five ports to start
an EE connection in a previous release, you must code the start option
EEVERIFY=NEVER before you start VTAM.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you are using less than five ports for all of your EE connections,
then you need to specify the EEVERIFY=NEVER start option.</li>
<li>If you have specific EE connections, you need to specify EEVERIFY=NEVER
on the PU or GROUP statement for that EE connection.</li></ul>
<p><strong>Reference information:</strong> Refer to <a href="../com.ibm.zos.r13.istrdr0/eeverifymm.htm">start option EEVERIFY </a> in >z/OS Communications Server: SNA Resource Definition Reference</a>.</p>
<h3 id="multpth">SNA Services: Code MULTPATH start option when using multipath</h3>
<p><strong>Description:</strong> Prior to z/OS V1R12, multipath support was enabled by a single
switch in the TCP/IP profile for both Enterprise Extender (EE) and
TCP/IP traffic. Beginning with z/OS V1R12,
multipath support is disabled (by default) for EE connections. If
you want to continue to use multipath for your EE connections, you
must code the start option MULTPATH=TCPVALUE before starting VTAM.<a id="idx476"></a></p>
<table id="wq326" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to continue using multipath
for EE connections.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Add MULTPATH=TCPVALUE to the VTAM start option file ATCSTR<var class="pv">xx</var>.</p>
<p><strong>Reference information:</strong> For details about RTP
performance problems over EE with multipath routing enabled, see >z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures</a>.</p>
<h2 id="wq327">Communications Server actions to perform after the first IPL
of z/OS V1R13</h2>
<p>This topic describes Communications Server migration actions that
you can perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these actions.</p><a id="idx477"></a><a id="idx478"></a><a id="idx479"></a><a id="idx480"></a><a id="idx481"></a><a id="idx482"></a>
<h3 id="ipvpref">IP Services: Ensure that preference values associated with
IPv6 router advertisement routes are as expected</h3>
<p>Starting in z/OS V1R12,
TCP/IP processes preference values that are provided in IPv6 router
advertisement messages.  Prior to z/OS V1R12,
all router advertisement routes were generated with a medium
preference value.</p><a id="idx483"></a><a id="idx484"></a><a id="idx485"></a>
<table id="wq328" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your stack is IPv6 enabled and your
adjacent routers are originating IPv6 router advertisement messages
that contain preference values other than the default value (medium)
for either the default route or an indirect prefix route.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Review the reference information for a description of how z/OS Communications Server uses
the preference values that are received in IPv6 router advertisement
messages.</li>
<li>Ensure that the preference values associated with the router advertisement
routes generated from information received in router advertisement
messages are as expected.</li>
<li>If any preference values differ from what you expected, make the
necessary configuration changes on the advertising routers.</li></ol>
<p><strong>Reference information:</strong> For details, see the
IPv6 routing topic in >z/OS Communications Server: IPv6 Network and Application Design Guide</a>.</p>
<h1 id="ae1cryp">Cryptographic Services migration actions</h1>
<p>This topic describes migration actions for base element Cryptographic
Services. Included are the components Integrated Cryptographic Service
Facility (ICSF), Open Cryptographic Services Facility (OCSF), PKI
Services, and System Secure Sockets Layer (SSL).</p><a id="idx486"></a><a id="idx487"></a><a id="idx488"></a>
<h2 id="wq330">Cryptographic Services actions to perform before installing z/OS V1R13</h2>
<p>This topic describes Cryptographic Services migration actions that
you can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are made.</p><a id="idx489"></a><a id="idx490"></a><a id="idx491"></a><a id="idx492"></a>
<h3 id="icsfpkc">ICSF: Ensure PKCS #11 applications call C_Finalize() prior
to calling dlclose()</h3>
<p><strong>Description:</strong> A PKCS #11 application initializes
the environment by calling dlopen() to load the PKCS #11 DLL into
storage, and then calling C_Initialize(). Later, when processing is
complete, the application terminates processing by calling C_Finalize(),
and then calling dlclose(). Reinitialization, if desired, can be achieved
by calling dlopen() and C_Initialize() a second time.</p>
<p>In prior releases, z/OS PKCS
#11 allowed an application to implicitly finalize the environment
by calling dlclose() without first calling C_Finalize(). Starting
with ICSF FMID HCR7770, this is no longer be supported. If an application
does not call C_Finalize() prior to calling dlclose(), a subsequent
attempt to re-initialize PKCS #11 by calling C_Initialize() will result
in error CKR_FUNCTION_FAILED being returned.</p>
<table id="wq331" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>ICSF FMID HCR7770, which was initially made
available in web deliverable <em>Cryptographic Support
for z/OS V1R9-R11</em> and
is now integrated into z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without ICSF FMID HCR7770 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the following sequence of calls:
dlopen(), C_Initialize(), <em>processing functions</em>,
dlclose(), dlopen(), C_Initialize().</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> PKCS #11 application developers
must:</p>
<ol type="1">
<li>Scan their source code for the following sequence of calls: dlopen(),
C_Initialize(), <em>processing functions</em>, dlclose(),
dlopen(), C_Initialize().</li>
<li>Change all such sequences to insert a call to C_Finalize() before
the call to dlclose().</li></ol>
<p><strong>Reference information:</strong> For more information
on writing PKCS #11 applications, refer to >z/OS Cryptographic Services ICSF Writing PKCS #11 Applications</a>.</p>
<h2 id="wq333">Cryptographic Services actions to perform before the first
IPL of z/OS V1R13</h2>
<p>This topic describes Cryptographic Services migration actions that
you can perform after you have installed z/OS V1R13 but before the first time you IPL. These
actions might require the z/OS V1R13
level of code to be installed but do not require it to be active.</p><a id="idx493"></a><a id="idx494"></a><a id="idx495"></a><a id="idx496"></a><a id="idx497"></a><a id="idx498"></a>
<h3 id="icsfcsfpu">ICSF: Ensure the CSFPUTIL utility is not used to initialize
a PKDS</h3>
<p><strong>Description:</strong> ICSF provides a utility program,
CSFPUTIL, that performs certain functions that can also be performed
using the administrator's panels. In releases of ICSF prior to
FMID HCR7780 (available as web deliverable <em>Cryptographic
Support for z/OS V1R10-V1R12</em>),
you could use the CSFPUTIL utility program to initialize a PKDS, reencipher
a PKDS, and refresh the in-storage copy of the PKDS. You can still
use the CSFPUTIL utility to reencipher or refresh a PKDS. However,
starting with FMID HCR7780 (<em>Cryptographic Support
for z/OS V1R10-V1R12</em>,
now integrated into z/OS V1R13),
the CSFPUTIL utility program no longer supports the function to initialize
a PKDS. Instead, the ICSF panels must be used to initialize a PKDS.</p>
<p><a id="idx499"></a><a id="idx500"></a></p>
<table id="wq334" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>ICSF FMID HCR7780, which was initially made
available in web deliverable <em>Cryptographic Support
for z/OS V1R10-R12</em> and
is now integrated into z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
or z/OS V1R11 without ICSF
FMID HCR7780 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have jobs that use the the CSFPUTIL
utility program to initialize a PKDS.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Because of this change, jobs that call the CSFPUTIL
utility with the INITPKDS option will no longer initialize a PKDS,
and return code 4 (which indicates that supplied parameters are incorrect)
will be returned.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Make sure no jobs call CSFPUTIL
with the INITPKDS option. Use the administrator panels to initialize
the PKDS instead.</p>
<p><strong>Reference information:</strong> For more information
in initializing the PKDS and on the CSFPUTIL utility, refer to >z/OS Cryptographic Services ICSF Administrator&rsquo;s Guide</a>.</p>
<h3 id="modstrt">ICSF: Modify ICSF startup procedure</h3>
<p><strong>Description:</strong> The program that started ICSF
in earlier releases was named CSFMMAIN. In ICSF FMID HCR7770 (initially
made available in the web deliverable <em>Cryptographic
Support for z/OS V1R9-R11</em> and
now integrated into z/OS V1R12),
the CSFMMAIN program is replaced by the CSFINIT program. If your ICSF
startup procedure is not modified to run this new program, the procedure
will not start the HCR7770 level of ICSF.<a id="idx501"></a><a id="idx502"></a></p>
<table id="wq335" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>ICSF FMID HCR7770, which was initially made
available in web deliverable <em>Cryptographic Support
for z/OS V1R9-R11</em> and
now integrated into z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without ICSF FMID HCR7770 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use CSFMMAIN as the ICSF startup
program.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>In your startup procedure for ICSF: 
<ol type="1">
<li>Find the job step that identifies the ICSF startup program (CSFMMAIN)
that was used in earlier releases. For example:
<pre class="xmp"><code>CSFSTART EXEC PGM=CSFMMAIN,REGION=0M,TIME=1440</code></pre></li>
<li>Modify the PGM parameter on this EXEC statement to identify the
new startup program (CSFINIT):
<pre class="xmp"><code>CSFSTART EXEC PGM=CSFINIT,REGION=0M,TIME=1440</code></pre></li>
<li>Save your changes to the startup procedure.</li></ol></li></ul><strong>Tips:</strong><p class="indatacontent"> </p>
<ul>
<li>Member CSF in SYS1.SAMPLIB contains a sample JCL code for an ICSF
startup procedure.</li>
<li>The new PPT entry for CSFINIT is shipped in the IBM default PPT table by APAR OA26245 for z/OS V1R9 and z/OS V1R10.</li>
<li>Refer to Washington Systems Center (WSC) Flash FLASH10620 for
tips about sharing the ICSF startup procedure between ICSF release
levels.</li>
<li>In HCR7770 and later, ICSF PKCS11 requests above the
bar memory. ABENDDC2-16 in CSFKSTDC can be encountered because of
a large number of TKDS requests. System programmers can code MEMLIMIT=NOLIMIT
in the new ICSF startup procedures to prevent an ABENDDC2 when system
limits for above the bar memory are set too low. For more information,
see <a href="http://www-01.ibm.com/support/docview.wss?uid=isg1OA34077">http://www-01.ibm.com/support/docview.wss?uid=isg1OA34077 </a>.</li></ul><a id="idx503"></a><a id="idx504"></a><a id="idx505"></a>
<p><strong>Reference information:</strong> For more information
on ICSF startup procedures, refer to >z/OS Cryptographic Services ICSF System Programmer&rsquo;s Guide</a>.</p>
<h3 id="ae3ois">OCSF: Migrate the directory structure</h3>
<p><strong>Description:</strong> If you previously configured
Open Cryptographic Services Facility (OCSF), you need to verify that
the OCSF directories have been migrated to the target system.</p>
<div>
<div class="notetitle" id="wq337">Note:</div>
<div class="notebody"> If you want to take advantage of the new Software
Cryptographic Service Provider 2 (SWCSP2), you should bypass this
migration action.  When your z/OS V1R11
system is up and running, install OCSF by running the install script
and then the IVP.</div></div><a id="idx506"></a>
<table id="wq338" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use OCSF or if new products
or functions on your new z/OS system
require OCSF to be active. However, if you installed your new z/OS system with ServerPac or SystemPac, the OCSF installation
script has been run and you do not have to perform this migration
action for that system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Migrate the OCSF <samp class="xph">/var</samp> directory
structure to the target system. If you installed z/OS V1R11 with CBPDO or by cloning an already-installed
V1R11 system, you can either copy  the <samp class="xph">/var/ocsf</samp> directory
from your old system or rerun the installation script. If you installed z/OS V1R11 with ServerPac or SystemPac, the OCSF installation
script has been run and you have no migration actions for that target
system (although you still have to migrate the directory structure
to any cloned systems, as stated above).</p>
<p>If you copy <samp class="xph">/var/ocsf</samp>, verify that the OCSF <samp class="xph">/var</samp> directory
structure has been migrated to the target system as described in <a href="#at3gend">Migrate /etc and /var system control files</a>. The OCSF registry (the <samp class="xph">/var/ocsf</samp> files)
contains the directory path names to the code libraries. If the registry
files are copied, the CSSM DLL and the add-ins must be in the same
location on the target system as on the prior release.  The normal
locations are <samp class="xph">/usr/lpp/ocsf/lib</samp> for the CSSM and supporting
DLLs and <samp class="xph">/usr/lpp/ocsf/addins</samp> for the add-in libraries.</p>
<p>If you copied <samp class="xph">/var/ocsf</samp>, do the following:</p>
<ol type="1">
<li>Verify that the following four files exist in that directory:
<ul>
<li>CDSA_Registry.dir with permissions (-rw-r--r--)</li>
<li>CDSA_Registry.pag with permissions ( -rw-r--r--)</li>
<li>CDSA_Sections.dir with permissions (-rw-r--r-- )</li>
<li>CDSA_Sections.pag with permissions (-rw-r--r--)</li></ul></li>
<li>Verify that the required RACF FACILITY
class profiles are defined and set up:<a id="idx507"></a>
<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data
storage library (DL) service provider</li></ul></li>
<li>Ensure that the necessary libraries are program controlled:
<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li></ol>
<p>If you did not copy <samp class="xph">/var/ocsf</samp>, rerun the installation
script: </p>
<ol type="1">
<li>Set up the RACF FACILITY
class profiles required by OCSF and authorize the appropriate
user IDs to those profiles:
<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data
storage library (DL) service provider</li></ul></li>
<li>Ensure that the following libraries are defined as program controlled:
<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li>
<li>Run the <strong>ocsf_install_crypto</strong> script from
the OMVS shell. This must be run from the target system. 
<ol type="a">
<li>Verify and update $LIBPATH.</li>
<li>Change directory to the location of the script (<samp class="xph">/usr/lpp/ocsf/bin</samp>).</li>
<li>Run the script.</li></ol></li></ol>
<p>Whether you reinstalled or migrated, it is strongly recommended
that you rerun IVP <strong>ocsf_baseivp</strong> from the OMVS
shell. This IVP verifies that OCSF is installed and configured correctly.
To run the IVP:</p>
<ol type="1">
<li>Mount <samp class="xph">/usr/lpp/ocsf/ivp</samp>.</li>
<li>Read the README file and follow the instructions.</li>
<li>Run the IVP.</li></ol>
<p>If you were using other IBM or
non-IBM services to supplement the functions in OCSF, such as the
Open Cryptographic Enhanced Plug-ins (OCEP) component of base element
Integrated Security Services, or the PKI Services component of base
element Cryptographic Services, you must ensure that these are migrated
or reinstalled.</p>
<p><strong>Reference information:</strong> >z/OS Open Cryptographic Services Facility Application Programming</a>.</p><a id="idx508"></a>
<h3 id="pkcscert">System SSL: Ensure PKCS #11 tokens contain complete certificate
chains</h3>
<p><strong>Description:</strong> The PKCS #11 token certificate
validation process should retrieve and validate the complete chain
of certificates up to a root (self-signed) certificate. Prior to V1R12,
however, System SSL may have successfully validated an incomplete
certificate chain when retrieving a certificate from a PKCS #11 token.
In System SSL V1R12, the certificate validation process has been improved,
and access to the complete certificate chain is required for successful
certificate validation. Implementations using PKCS #11 tokens containing
incomplete certificate chains may find that certificates that passed
validation in releases prior to z/OS V1R12
now fail validation in z/OS V1R12.<a id="idx509"></a></p>
<table id="wq343" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if PKCS #11 tokens are being used by a
System SSL application.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure that PKCS #11 tokens
being used by System SSL applications contain the complete certificate
issuer chain up to a root (self-signed) certificate. You can use the z/OS shell-based program <strong>gskkyman</strong> or the z/OS Security
Server (RACF) <span class="pk">RACDCERT</span> command
to display supported tokens and their certificates.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For additional information about certificate validation and the <strong>gskkyman</strong> command, refer to >z/OS Cryptographic Services System SSL Programming</a>.</li>
<li>For additional information about the <span class="pk">RACDCERT</span> command,
refer to >z/OS Security Server RACF Command Language Reference</a>.</li></ul>
<p></p><a id="idx510"></a>
<h3 id="ssltlsr">System SSL: Modify applications to address disablement of SSL
V3 and TLS session renegotiation</h3>
<p><strong>Description:</strong> Session renegotiation allows
an existing SSL V3 or TLS session to perform a re-handshake.
 A common reason for this is to refresh the session keys used to encrypt
data transmitted across the secure connection. In z/OS V1R11, z/OS V1R10,
and z/OS V1R9 without the PTFs
for APAR OA31172 installed, the default behavior of System SSL was
to permit applications to perform SSL V3 and TLS server session renegotiations according
to the SSL V3 Protocol Specification and RFC2246. The new default
behavior for z/OSV1R11, with the PTFs for APAR  OA31172 installed,
is to disable session renegotiation.</p>
<p>If you run System SSL applications that handle session renegotiation,
server renegotiation will fail unless renegotiation is explicitly
enabled. The gsk_secure_socket_read API will return with error code
432. The gsk_secure_soc_read API will return with error code -7.</p>
<p><a id="idx511"></a><a id="idx512"></a></p>
<table id="wq344" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11, z/OS V1R10, and z/OS V1R9 by APAR OA31172.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without the PTFs for APAR OA31172 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you run any System SSL applications
that request or receive requests for session renegotiation.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Identify the System SSL applications your installation runs, and
determine whether any of those applications require session renegotiation.
If no applications require session renegotiation, no further action
is needed.</li>
<li>If any System SSL applications your installation runs attempts
session renegotiation, determine whether this renegotiation is required. 
<ul>
<li>If the renegotiation is not required, modify the application so
that it does not attempt session renegotiation.</li>
<li>If server session renegotiation is necessary, and you are willing
to accept potential risks, server session renegotiation can be explicitly
enabled.
<ul>
<li>For applications that accept the specification of environment
variables, the  GSK_RENEGOTIATION environment variable should be used.
<ul>
<li>Specify GSK_RENEGOTIATION=NONE to disable SSL V3 and TLS handshake
renegotiation as a server. This is the default.</li>
<li>Specify GSK_RENEGOTIATION=ALL to allow SSL V3 and TLS handshake
renegotiation as a server. This is equivalent to the System SSL behavior
for session renegotiation.</li>
<li>Specify GSK_RENEGOTIATION=ABBREVIATED to allow SSL V3 and TLS
abbreviated handshake renegotiation as a server for resuming the current
session only, while disabling SSL V3 and TLS full handshake renegotiation
as a server.  The System SSL session ID cache is not checked when
resuming the current session with this value set.</li></ul></li>
<li>For applications that don't allow the specification of environment
variables or want to tailor individual SSL environments within an
application, use the enumeration identifier GSK_RENEGOTIATION on thegsk_attribute_set_enum
API. For the GSK_RENEGOTIATION enumeration identifier:
<ul>
<li>Specify GSK_RENEGOTIATION_NONE to disable SSL V3 and TLS handshake
renegotiation as a server.  This is the default.</li>
<li>Specify GSK_RENEGOTIATION_ALL to allow SSL V3 and TLS handshake
renegotiation as a server.</li>
<li>Specify GSK_RENEGOTIATION_ABBREVIATED to allow SSL V3 and TLS
abbreviated handshake renegotiation as a server for resuming the current
session only, while disabling SSL V3 and TLS full handshake renegotiation
as a server.  With this enumeration value set, the System SSL session
ID cache is not checked when resuming the current session.</li></ul>The gsk_attribute_get_enum API also accepts the  enumeration
identifier GSK_RENEGOTIATION, and will return one of the preceding
enumeration values indicating the current renegotiation setting for
the specified SSL environment.</li></ul></li></ul></li></ol>
<p><strong>Reference information:</strong> For information about
System SSL programming, refer to >z/OS Cryptographic Services System SSL Programming</a>.</p>
<h3 id="csfserv">System SSL: Ensure all RACF user
IDs that start SSL applications can access the CSFIQA resource of
the CSFSERV class</h3>
<p><strong>Description:</strong> When the System SSL DLLs are
loaded, System SSL determines which hardware is available. Starting
in z/OS V1R13, System SSL uses
the ICSF Query Algorithm callable service (CSFIQA) to retrieve information
about the cryptographic algorithms that are available. However, if
the user ID that starts the SSL application cannot access the CSFIQA
resource of the CSFSERV class, System SSL will not be be able to retrieve
information using the CSFIQA callable service, and the informational
message ICH408I (which indicates insufficient authorization) may be
issued to the console. Although System SSL processing will continue,
System SSL may not be aware of all the hardware that is currently
available.<a id="idx513"></a><a id="idx514"></a></p>
<table id="wq346" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if: 
<ul>
<li>Your installation uses ICSF,</li>
<li>the CSFSERV general resource class is active, and</li>
<li>a profile covering the CSFIQA resource of the CSFSERV class is
defined and does not grant READ access to all users.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If your installation uses
ICSF, you should ensure that any RACF user
ID that will start SSL applications can access the CSFIQA callable
service. This includes the SSL started task (GSKSRVR), and the gskkyman
and gsktrace utilities.</p>
<ol type="1">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and specifically the CSFIQA
callable service) is unrestricted. No configuration is necessary.
 
<p>To determine which RACF classes
are currently active, enter the SETROPTS command with LIST parameter
specified:</p>
<pre class="xmp"><code>SETROPTS LIST</code></pre></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile that covers the CSFIQA resource. This could be
a discrete profile named CSFIQA or, if generic profile checking is
activated, a generic profile.  
<p>To determine if a profile has been
defined to protect the CSFIQA resource, enter the following RLIST
command:</p>
<pre class="xmp"><code>RLIST CSFSERV CSFIQA</code></pre>When you enter this command, RACF lists information for the
discrete resource profile CSFIQA.  If there is no matching discrete
profile, RACF will list the
generic profile that most closely matches the resource name.</li>
<li>If the RLIST command output revealed that there is a discrete
or generic profile defined that covers the CSFIQA resource, examine
the command output to ensure that all RACF user
IDs that may start System SSL applications have at least READ access
to the CSFIQA resource. If necessary, use the PERMIT command to give
the appropriate users or groups access. For example, if a discrete
profile CSFIQA exists, the following command would give user BAILEY
access.  
<pre class="xmp"><code>PERMIT CSFIQA CLASS(CSFSERV) ID(BAILEY) ACCESS(READ)</code></pre> 
If you do make any changes, refresh the in-storage RACF profiles for the CSFSERV class:  
<pre class="xmp"><code>SETROPTS RACLIST(CSFSERV) REFRESH</code></pre></li></ol>
<p><strong>Reference information:</strong> For additional information
about System SSL use of ICSF callable services, see <cite></cite>.</p>
<p>For additional information about ICSF CSFSERV resource class, see <cite></cite>.</p>
<h2 id="wq348">Cryptographic Services actions to perform after the first IPL
of z/OS V1R13</h2>
<p>This topic describes Cryptographic Services migration actions that
you can perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these actions.</p><a id="idx515"></a><a id="idx516"></a><a id="idx517"></a><a id="idx518"></a><a id="idx519"></a><a id="idx520"></a>
<h3 id="pmr74338">ICSF: Ensure the expected master key support is available</h3>
<p><strong>Description: </strong> In versions of ICSF prior to
FMID HCR7780, in order for a coprocessor to become active, a DES master
key needed to be set on the coprocessor. Once the coprocessor was
active, DES master key support, and the support of any other master
key (an AES master  key or an asymmetric master key) set on the coprocessor,
would then be available.<a id="idx521"></a><a id="idx522"></a></p>
<p>Starting with ICSF FMID HCR7780, the activation procedure for non-CCF
systems is designed to maximize the number of active coprocessors
by selecting the set of master keys that are available on the majority
of coprocessors. A DES master key is no longer required in order for
a coprocessor to become active. Instead, any one of four master keys -
the DES master key, the AES master key, the RSA master key (which
in earlier releases was called the asymmetric master key), or the
ECC master key - is enough for a  coprocessor to become active.
However, because the goal is to select the combination of master keys
that will maximize the number of  active coprocessors, if a certain
master key is not set on all the same coprocessors, that master key
support will not be available. Before you use ICSF FMID HCR7780, you
must understand the new method of coprocessor activation in order
to ensure that the expected master keys will be available. You may
need to set master keys on additional coprocessors to ensure the same
master key support you had in earlier versions of ICSF is available
in ICSF FMID HCR7780.</p>
<table id="wq349" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>ICSF FMID HCR7780, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R10-R12 and is now integrated
into z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
or z/OS V1R11 without ICSF
FMID HCR7780 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Make sure you understand the
new method of coprocessor activation described in this migration action
to ensure the expected master key support is available.</p>
<p>To further illustrate the change in coprocessor activation introduced
in ICSF FMID HCR7780, let&rsquo;s say you have the following four coprocessors
with these master keys set (as indicated by the letter &quot;Y&quot;).</p>
<table id="wq350" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 10. Coprocessor activation example</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq351" align="left"></th>
<th id="wq352" align="center">E00</th>
<th id="wq353" align="center">E01</th>
<th id="wq354" align="center">E02</th>
<th id="wq355" align="center">E03</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq351"><strong>DES</strong></td>
<td align="center" headers="wq352">Y</td>
<td align="center" headers="wq353"></td>
<td align="center" headers="wq354">Y</td>
<td align="center" headers="wq355"></td>
</tr>
<tr>
<td headers="wq351"><strong>AES</strong></td>
<td align="center" headers="wq352">Y</td>
<td align="center" headers="wq353">Y</td>
<td align="center" headers="wq354">Y</td>
<td align="center" headers="wq355">Y</td>
</tr>
<tr>
<td headers="wq351"><strong>RSA (ASYM)</strong></td>
<td align="center" headers="wq352">Y</td>
<td align="center" headers="wq353"></td>
<td align="center" headers="wq354">Y</td>
<td align="center" headers="wq355"></td>
</tr>
</tbody>
</table>
<p>In releases prior to ICSF FMID HCR7780, a DES master key was required
in order for a coprocessor to become active. In our example, coprocessors
E00 and E02 have the DES master key set, so they become active. The
DES master key is available as well as the AES and RSA (ASYM) master
keys which are set on the E00 and E02 coprocessors. Coprocessors E01
and E03 do not have a DES master key set, and so are not active.</p>
<p>Starting with ICSF FMID HCR7780, any master key is enough for a
coprocessor to become active and the activation procedure tries to
maximize the number of active coprocessors. The AES master key is
set on all four of these coprocessors, so all four of the coprocessors
become active. However, since the DES and RSA master keys are not
set on all four of the coprocessors, DES and RSA support is not  available.
As coprocessor master keys are set or changed, however, additional
function may become available. In this case, setting the DES and RSA
master keys on coprocessors E01 and E03 would make the DES and RSA
support available.</p>
<p>ECC master key support is based on the existence of CEX3C coprocessors.
If a mixture of CEX3C coprocessors and older coprocessors exist on
a system, then ECC support will be based solely on the state of the
CEX3C coprocessors. For example, let's change our example so that
 two of the coprocessors are CEX3C coprocessors (as identified by
the G prefix in the name) with the ECC master key set.</p>
<table id="wq356" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 11. Coprocessor activation example (ECC support based only on CEX3C coprocessors)</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq357" align="left"></th>
<th id="wq358" align="center">G00</th>
<th id="wq359" align="center">E01</th>
<th id="wq360" align="center">G02</th>
<th id="wq361" align="center">E03</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq357">DES</td>
<td align="center" headers="wq358">Y</td>
<td align="center" headers="wq359"></td>
<td align="center" headers="wq360">Y</td>
<td align="center" headers="wq361"></td>
</tr>
<tr>
<td headers="wq357">AES</td>
<td align="center" headers="wq358">Y</td>
<td align="center" headers="wq359">Y</td>
<td align="center" headers="wq360">Y</td>
<td align="center" headers="wq361">Y</td>
</tr>
<tr>
<td headers="wq357">RSA (ASYM)</td>
<td align="center" headers="wq358">Y</td>
<td align="center" headers="wq359"></td>
<td align="center" headers="wq360">Y</td>
<td align="center" headers="wq361"></td>
</tr>
<tr>
<td headers="wq357">ECC</td>
<td align="center" headers="wq358">Y</td>
<td align="center" headers="wq359"></td>
<td align="center" headers="wq360">Y</td>
<td align="center" headers="wq361"></td>
</tr>
</tbody>
</table>
<p>In this example, the AES master key is still the one set on the
majority of coprocessors and makes the coprocessors active. The DES
and RSA master keys are not set on all the coprocessors, and so DES
and RSA support is not available. The ECC master key cannot be set
on all coprocessors (because it is not available on the CEX2C). However,
unlike the DES and RSA support, ECC support is still available. This
is because the ECC master key is set on  all CEX3C coprocessors.</p>
<p>To ensure the master key support that you expect is available,
follow these steps:</p>
<ol type="1">
<li>To ensure AES support, set the AES master key on each CEX2C and
CEX3C.</li>
<li>To ensure DES support, set the DES master key on each CEX2C, CEX3C,
and (as long as AES support is not also needed) PCIXCC.</li>
<li>To ensure RSA support, set the RSA master key on each CEX2C, CEX3C,
and (as long as AES support is not also needed) PCIXCC.</li>
<li>To ensure ECC support, set the ECC master key on each CEX3C.</li></ol>
<p>To verify the master key support is available, select option 1,
COPROCESSOR MGMT, from the ICSF Primary menu. This will display the
coprocessor management panel, which shows which coprocessors are active,
and the state of the master keys for coprocessors.</p>
<p><strong>Reference information:</strong></p>
<ul>
<li>For information about entering master key parts, see >z/OS Cryptographic Services ICSF Administrator&rsquo;s Guide</a>.</li>
<li>Search for TechDoc "Activation of Cryptographic Coprocessors and
Cryptographic Algorithms with ICSF, HCR7780", at <a href="http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs">http://www.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs</a>.</li></ul>
<h3 id="pkichng">PKI Services: Change the time at which the daily maintenance
task runs</h3>
<p><strong>Description:</strong> Before z/OS V1R12, PKI Services ran a daily maintenance
task when you started the PKI Services daemon, and every twenty-four
hours after that. Starting with z/OS V1R12,
by default the task runs when you start the PKI Services daemon, and
daily at midnight local time. If running this task at midnight causes
problems, for example performance problems because you have other
tasks scheduled to run at midnight, you can change the time at which
the PKI Services daily maintenance task runs.<a id="idx523"></a><a id="idx524"></a><a id="idx525"></a><a id="idx526"></a></p>
<table id="wq363" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want the PKI Services daily
maintenance task to run at midnight.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Change the value of the MaintRunTime
variable in the PKI Services configuration file to specify the time
at which you want the daily maintenance task to run.</p>
<p><strong>Reference information:</strong> For details about
updating the MaintRunTime variable, see >z/OS Cryptographic Services PKI Services Guide and Reference</a>.</p>
<h1 id="af1dfsm">DFSMS migration
actions</h1>
<p>This topic describes migration actions for base element DFSMSdfp and
optional features DFSMSdss, DFSMShsm, DFSMSrmm,
and DFSMStvs.</p><a id="idx527"></a>
<h2 id="wq364">DFSMS actions
to perform before installing z/OS V1R13</h2>
<p>This topic describes DFSMS migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p><a id="idx528"></a><a id="idx529"></a><a id="idx530"></a><a id="idx531"></a>
<h3 id="ax3eisc">DFSMSdfp:
Back up SMS control data sets</h3>
<p><strong>Description:</strong> In a multisystem Storage Management
Subsystem (SMS) complex, operating systems share a common set of SMS
classes, groups, ACS routines, and a configuration base, which make
up the storage management policy for the complex. This storage management
policy is maintained in a source control data set (SCDS). When this
policy is activated for SMS, the bound policy is maintained in processor
storage and on DASD in an active control data set (ACDS). Systems
in the complex communicate SMS information through a common communications
data set (COMMDS).</p><a id="idx532"></a><a id="idx533"></a><a id="idx534"></a><a id="idx535"></a><a id="idx536"></a><a id="idx537"></a><a id="idx538"></a><a id="idx539"></a><a id="idx540"></a><a id="idx541"></a>
<p>It is recommended that to successfully share SMS control data sets
in a multisystem environment where there are mixed levels of DFSMS, you update,
translate, validate, and activate SMS policies on the system with
the latest level of DFSMS.
When an earlier control data set is to be updated or activated, the
control data set is formatted by the later-level system. The shared
SMS control blocks reflect the new, rather than the previous, lengths
and control information.</p>
<p>For fallback, IBM recommends
restoring SMS control data sets from backups taken on the fallback
release.</p>
<p>Editing a policy on an earlier system could invalidate unused control
information and prevent the control data set from being accessed by
a later system.  A warning message is provided before a policy can
be changed on an earlier system. ACS routines may need to be updated
and translated so to not reference policy items not known to the earlier
system.</p>
<p>Remember, you risk policy activation failures if SCDS changes are
not validated using the latest-level system in a sysplex.</p>
<table id="wq365" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure data integrity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Install the PTFs in <a href="#coxptfs">Install coexistence and fallback PTFs</a> if
they are not already installed.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Do the following
on your pre-z/OS V1R13 systems:</p>
<ol type="1">
<li>Back up SMS control data sets according to established procedures
in the event that fallback is required. The control data set format
is VSAM linear.</li>
<li>Install all coexistence PTFs in <a href="#coxptfs">Install coexistence and fallback PTFs</a>.</li></ol>
<p>In addition, if you modified and activated a higher-level
policy on a pre-z/OS V1R13 system, do the following to ensure
that the ACDS can be accessed on z/OS V1R13:</p>
<ol type="1">
<li> On the pre-z/OS V1R13 system, save the active ACDS as
an SCDS with the SETSMS SAVESCDS command.</li>
<li>On z/OS V1R13, update,
translate, validate, and activate the saved SMS policy.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS DFSMS Implementing System-Managed Storage</a></li>
<li>>z/OS DFSMSdfp Storage Administration</a></li></ul>
<h3 id="listcsi">DFSMSdfp: Accommodate deletion of NOIMBED and NOREPLICAT
LISTCAT command attributes</h3>
<p><strong>Description:</strong> Before z/OS V1R13, output from the IDCAMS LISTCAT command
displayed the NOIMBED and NOREPLICAT attributes. Starting with z/OS V1R13, these attributes are
no longer included in the LISTCAT command output. This might affect
programs that parse LISTCAT results.</p>
<p>In 2001, support for creating data sets with IMBED or REPLICATE
attributes on the AMS DEFINE command was removed. Starting with z/OS V1R13, the LISTCAT output
no longer displays the default NOIMBED and NOREPLICAT attributes.
This information is no longer needed. This might affect programs that
parse LISTCAT results.</p>
<p>Note that for any cluster defined prior to 2001 with IMBED or REPLICATE
attributes, those attributes are displayed in IDCAMS LISTCAT command
output.</p>
<p>Before this z/OS V1R13
change, when you issued a LISTCAT for a data set, at the end, you
would see attribute characteristics. They would look something like
this example:</p>
<pre class="xmp"><code> ATTRIBUTES
  KEYLEN----------------15     AVGLRECL--------------80 
  RKP--------------------0     MAXLRECL--------------80 
  STRIPE-COUNT-----------1

  SHROPTNS(4,3)   RECOVERY     UNIQUE           NOERASE     INDEXED      NOWRITECHK     NOIMBED       NOREPLICAT
  UNORDERED        NOREUSE     NONSPANNED      EXTENDED     EXT-ADDR </code></pre>
<p>Starting with z/OS VR13,
when you issue a LISTCAT for a data set, the result will look something
like this example:</p>
<pre class="xmp"><code>ATTRIBUTES
  KEYLEN----------------15     AVGLRECL--------------80 
  RKP--------------------0     MAXLRECL--------------80 
  STRIPE-COUNT-----------1

  SHROPTNS(4,3)   RECOVERY     UNIQUE           NOERASE     INDEXED      NOWRITECHK    UNORDERED      NOREUSE
  NONSPANNED      EXTENDED     EXT-ADDR </code></pre>
<p><a id="idx542"></a></p>
<table id="wq368" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td> DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use programs that
parse LISTCAT results.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> It is recommended that you
convert the programs that parse LISTCAT results to use Catalog Search
Interface (CSI).</p>
<p><strong>Reference information:</strong> See information about
CSI in >z/OS DFSMS Managing Catalogs</a>.</p><a id="idx543"></a><a id="idx544"></a><a id="idx545"></a><a id="idx546"></a>
<h3 id="capunca">DFSMSdfp: Modify exit routines to support 31-bit UCB
addresses</h3>
<p><strong>Description:</strong> Before z/OS V1R12, DADSM captured the unit control block
(UCB) address passed to it in its interfaces. Starting in z/OS V1R12, DADSM will no longer
capture the UCB address passed to it and will use the actual 31-bit
UCB address. The UCB address will either be above or below the 16
MB line. This address in turn will be passed into the DADSM pre-
and post- installation exit routines (IGGPRE00, IGGPOST0) in
the current 4-byte IEXUCB field. Therefore, the address in
IEXUCB may now contain a 31-bit UCB address. Exit routines
that do not support 31-bit UCB addresses will need to be upgraded
to support a 31-bit UCB address.<a id="idx547"></a></p>
<table id="wq369" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes. If an exit routine does not support 31-bit
UCB, it will need to be upgraded to support 31-bit UCB addresses.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update the exit to support
a 31-bit UCB address.</p>
<p><strong>Reference information:</strong> For details about
DADSM pre- and post-installation exit routines, see >z/OS DFSMS Installation Exits</a>.</p>
<h3 id="vsamirk">DFSMSdfp and
DFSMSdss: Redefine existing VSAM data sets that contain the IMBED,
REPLICATE, and KEYRANGE attributes</h3>
<p><strong>Description:</strong> No supported release of z/OS honors the IMBED, REPLICATE,
and KEYRANGE attributes for new VSAM data sets. In fact, using these
attributes can waste DASD space and often degrades performance. Servicing
these VSAM data sets has become increasingly difficult. In some cases,
unplanned outages have occurred. For these reasons, IBM recommends that you stop using IMBED and
REPLICATE, and that you minimize or eliminate your use of KEYRANGE.<a id="idx548"></a><a id="idx549"></a><a id="idx550"></a><a id="idx551"></a></p>
<p>IMBED and REPLICATE were intended as performance improvements and
have been rendered obsolete by newer, cached DASD devices. Striped
data sets provide much better performance than KEYRANGE and should
be viewed as a candidate for any existing KEYRANGE data sets.</p>
<p>Starting in z/OS V1R12,
DFSMSdss provides some assistance in identifying and converting data
sets with KEYRANGES, IMBED or REPLICATE attributes: </p>
<ul>
<li>Data set dump processing and restore processing issue a message
ADR508I (<var class="pv">ttt</var>)-<var class="pv">mmmmm</var>(<var class="pv">yy</var>), THE FOLLOWING
DATA SETS REQUIRE SOME ACTION TO BE TAKEN when data sets with those
attributes are encountered.</li>
<li>Logical restore processing automatically converts indexed VSAM
data sets with the IMBED or REPLICATE attributes, but not the KEYRANGES
attribute, to key-sequenced data sets (KSDS) that do not have those
attributes. It also issues message ADR507I (<var class="pv">ttt</var>)-<var class="pv">mmmmm</var>(<var class="pv">yy</var>),
DATA SET <var class="pv">dsn</var> WAS RESTORED WITHOUT THE IMBED OR REPLICATE
ATTRIBUTES indicating that the data set has been converted.</li></ul>
<table id="wq370" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp and DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>The recommendation to migrate from IMBED, REPLICATE,
and KEYRANGE was originally made in the z/OS V1R6
timeframe. In Software Announcement 204-180 (RFA39951), dated
August 10, 2004, IBM announced
its intent to withdraw support for VSAM IMBED, REPLICATE, and KEYRANGE
attributes in a future release. Based on customer feedback, IBM no longer plans to remove this
support from z/OS in the foreseeable
future. IBM still recommends
that you stop using these attributes and plans to remove IMBED and
REPLICATE attributes during logical DFSMSdss restore operations and
DFSMShsm recall operations as announced in Software Announcement 207-175
4 (RFA45594), dated August 7, 2007. The DFSMSdss function to
aid in conversion was added in z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid degraded performance
and wasted DASD space.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>HSM only logs messages for non-zero return codes
(non I-type), so the messages for this line item won't be logged by
HSM for any function.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check CATALOG_IMBED_REPLICATE on z/OS V1R11 to detect IMBED and
REPLICATE attributes in your master catalog and any connected user
catalogs.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Determine which VSAM data sets and ICF catalogs were defined with
the IMBED, REPLICATE, or KEYRANGE attribute. Data set dump processing
and restore processing issue message ADR508I (<var class="pv">ttt</var>)-<var class="pv">mmmmm</var>(<var class="pv">yy</var>),
THE FOLLOWING DATA SETS REQUIRE SOME ACTION TO BE TAKEN to indicate
data sets with the attributes. 
<p>To further help you identify the
data sets, you can get a tool that reads existing VSAM data sets and
ICF catalogs, and reports which ones have these attributes. The tool
is available from the software server (ftp.software.ibm.com) in the
s390/mvs/tools directory as IMBDSHIP.JCL.TRSD. Download the file in
binary format and unterse it on your z/OS system
using AMATERSE or TRSMAIN. Instructions for using the tool are included
in the downloaded JCL.</p>
<div>
<div class="notelisttitle" id="wq372">Notes:</div>
<ol type="a">
<li>The tool only checks data sets that are on DASD.</li>
<li>&quot;AMATERSE&quot; and &quot;TRSMAIN&quot; are names for a service aid
that compresses and decompresses data exchanged with IBM. &quot;AMATERSE&quot; is the preferred program name
since its integration into z/OS V1R9. &quot;TRSMAIN&quot; is
the original program name and is now shipped as an alias entry point
to AMATERSE. For more information about AMATERSE, including several
differences with TRSMAIN, see >z/OS MVS Diagnosis: Tools and Service Aids</a>.</li>
</ol></div></li>
<li>Schedule a time for the affected VSAM data sets and ICF catalogs
to be unavailable, and redefine them. 
<p>For VSAM data sets you can use JCL similar to the following:</p>
<pre class="xmp"><code>//* EXPORT A KSDS                                            
//STEP1   EXEC PGM=IDCAMS                                    
//SYSPRINT DD SYSOUT=*                                       
//INDD     DD DSN=EXAMPLE.KSDS,DISP=OLD                      
//OUTDD    DD DSN=EXAMPLE.KSDS.EXPORTED,DISP=(NEW,CATLG),    
//      SPACE=(CYL,(1,1)),UNIT=SYSDA                         
//SYSIN    DD *                                              
    EXPORT EXAMPLE.KSDS -                                    
    INFILE(INDD) -                                           
    OUTFILE(OUTDD) -                                         
    TEMPORARY                                                
                                                             
//* NOW IMPORT THE EXPORTED COPY                             
//STEP1   EXEC PGM=IDCAMS                                    
//SYSPRINT DD SYSOUT=*                                       
//INDD     DD DSN=EXAMPLE.KSDS.EXPORTED,DISP=SHR             
//SYSIN    DD *                                              
    IMPORT -                                                 
    INFILE(INDD) -                                           
    OUTDATASET(EXAMPLE.KSDS)                                 </code></pre>
<p>For
ICF catalogs, see informational APAR II13354 for step-by-step
instructions on using IDCAMS EXPORT/IMPORT with ICF catalogs.</p></li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about IDCAMS EXPORT and IMPORT, see >z/OS DFSMS Access Method Services for Catalogs</a>.</li>
<li>For more information about the AMATERSE service aid, see >z/OS MVS Diagnosis: Tools and Service Aids</a>.</li>
<li>For more information about data set dump and restore processing,
see >z/OS DFSMSdss Storage Administration</a>.</li>
<li>For more information about messages ADR507I and ADR508I, see >z/OS MVS System Messages, Vol 1 (ABA-AOM)</a>.</li></ul>
<h3 id="replcim">DFSMSrmm: Replace CIM providers and CIM classes</h3>
<p><strong>Description:</strong> In z/OS V1R10, the keys used for the DFSMSrmm CIM classes
were changed.  Prior to z/OS V1R12,
you had the option of using a backward-compatible CIM provider, rather
than updating your code to handle the new key formats.  Beginning
with z/OS V1R12, the backward-compatible
CIM provider is no longer supported. If you have not done so already,
you must unregister the previous CIM providers and CIM classes, and
register the currently supported CIM providers and CIM classes.<a id="idx552"></a><a id="idx553"></a><a id="idx554"></a></p>
<table id="wq374" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSrmm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have not yet updated your code to
handle the current key formats and are still using the backward-compatible
CIM provider (provided as rmmcim19.tar.Z compressed tar archive).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Update your code to handle the key formats used in z/OS V1R11 and later. For the current
formats, see <a href="#rmmcim">Table 12</a>.</li>
<li>Using the rmmutil.sh tool, unregister all the z/OS V1R9 CIM providers and unload all the z/OS V1R9 CIM classes.</li>
<li>Using the same rmmutil.sh tool, register the complete set of z/OS V1R12 CIM providers and load
the z/OS V1R12 CIM classes.</li></ol>
<p><a href="#rmmcim">Table 12</a> shows the old (V1R9) keys of DFSMSrmm CIM
classes and the current (V1R11 and later) compound keys, which have
formats of concatenated strings containing the values of the old keys
delimited with "+" and appended with spaces by the fix length, if
needed.</p>
<table id="rmmcim" width="100%" summary="" border="1" frame="border" rules="all">
<caption>Table 12. DFSMSrmm CIM classes and compound keys</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq376" width="32%" align="left">Class Name</th>
<th id="wq377" width="67%" align="left">Key Transformation</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq376">IBMRMM_Dataset</td>
<td headers="wq377">DataSetName,PhysicalFileSequenceNumber, VolumeSerialNumber,
and CdsID keys have been replaced with Name key of format DatasetName+FileSeq+Volser+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_Location</td>
<td headers="wq377">LocationName, LocationType, and CdsID keys have
been replaced with  Tag key of format LocationName+LocationType+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_LogicalVolume</td>
<td headers="wq377">VolumeSerialNumber and CdsID keys have been
replaced with  DeviceID key of format Volser+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_Owner</td>
<td headers="wq377">OwnerId and CdsID keys have been replaced with
 InstanceID key of format OrgID:OwnerID+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_PhysicalVolume</td>
<td headers="wq377">VolumeSerialNumber and CdsID keys have been
replaced with  Tag key of format Volser+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_PolicyRule</td>
<td headers="wq377">PolicyRuleType, PolicyRuleName, JobNameMask,
and CdsID keys have been replaced with  PolicyRuleName key of format
RuleType+RuleName+JobNameMask+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_Product</td>
<td headers="wq377">ProductNumber and CdsID keys have been replaced
with  IdentifyingNumber key of format ProductNumber+CdsID.</td>
</tr>
<tr>
<td headers="wq376">IBMRMM_ShelfLocation</td>
<td headers="wq377">LocationName, MediaName, ShelfLocationNumber,
and CdsID keys have been replaced with  Tag key of format LocationName+MediaName+Number+CdsID.</td>
</tr>
</tbody>
</table>
<p>Starting with z/OS V1R10,
in order to simplify processing of the compound keys, every changed
class has the KeyWithCdsIdName attribute containing the name of its
compound key. Additionally, <var class="pv">xxx</var>Format and <var class="pv">xxx</var>Mask
attributes are provided, where <var class="pv">xxx</var> is the name of the compound
key. For example, TagFormat property of IBMRMM_PhysicalVolume is set
to "Volser+CdsID" and TagMask string contains the consecutive concatenation
of six blanks, symbol "+", and eight blanks.</p>
<p><strong>Reference information:</strong> For additional details,
see the topic &quot;&quot; in >&amp;idarc00t;</a>.</p>
<h3 id="iggcat">DFSMSdfp: Define IGGCATxx parmlib member</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, if you do not use an
IGGCATxx parmlib member for catalog parameters, you might receive
system message IEA301I IGGCAT00 NOT FOUND IN PARMLIB.</p>
<p><a id="idx555"></a></p>
<table id="wq378" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid message IEA301I
referencing missing parmlib member IGGCATxx.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Do one of the following to
define parmlib member IGGCATxx to your system before IPLing V1R13
to prevent system message IEA301I referencing missing parmlib member
IGGCATxx:</p>
<ul>
<li>Create member IGGCAT00 in SYS1.PARMLIB or concatenation. Because
IGGCAT00 is the default, you do not have to specify <samp class="xph">00</samp> on
the CATALOG= parameter in parmlib member IEASYSxx.</li>
<li>Create IGGCATxx member(s) in SYS1.PARMLIB or concatenation. Specify
one or more members on the CATALOG= parameter of IEASYSxx so that
the system will search for and parse the specified members.</li></ul><p class="indatacontent">If you wish to take the default values set up for IGGCATxx, you
do not have to specify any parameters in the IGGCATxx member(s). The
system will find the member or members, and use the default parameter
values if none are specified in IGGCATxx.</p>
<p><strong>Reference information:</strong> For details about
the IGGCATxx parmlib member, see <cite></cite>.</p>
<h2 id="wq379">DFSMS actions
to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes DFSMS migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx556"></a><a id="idx557"></a><a id="idx558"></a><a id="idx559"></a><a id="idx560"></a><a id="idx561"></a>
<h3 id="af32b">DFSMSdfp:
Ensure that the Language
Environment runtime library is available for DLLs</h3>
<p><strong>Description:</strong> Language Environment provides
common services and language-specific routines in a single runtime
environment. You can use Language Environment to build and use dynamic link
libraries (DLLs) for applications.<a id="idx562"></a><a id="idx563"></a></p>
<table id="wq380" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation builds or references
DLLs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If your installation builds
or references DLLs, either you must set up the system link list to
refer to the Language
Environment runtime libraries (SCEERUN and SCEERUN2), or each
job that creates or uses a DLL must include a STEPLIB DD statement
referencing these libraries.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS Language Environment Run-Time Application Migration Guide</a></li>
<li>>z/OS Language Environment Customization</a></li>
<li>>z/OS Language Environment Programming Guide</a></li></ul>
<h3 id="af32e">DFSMSdfp:
Update SYS1.IMAGELIB</h3>
<p><strong>Description:</strong> If you use page mode printers
such as the IBM 3800 or the IBM 3900 running in line mode (not
page mode), you must install library character sets, graphic character
modification modules, and character arrangement tables in SYS1.IMAGELIB. <a id="idx564"></a><a id="idx565"></a><a id="idx566"></a>This migration action does not
apply if you are using IBM 3900
printers that are driven by PSF.</p>
<table id="wq381" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are not using your old SYS1.IMAGELIB,
you are installing with ServerPac or SystemPac, and you are using line mode printers
such as the 3800 or 3900.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>IBM 3800
or 3900 printers.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Run the LCSBLD1 job from the samplib data set to create character
sets, graphic character modification modules, and character arrangement
tables in SYS1.IMAGELIB.</li>
<li>Copy customized or locally-written FCBs and UCS images from your
old system's SYS1.IMAGELIB data set to the new system's SYS1.IMAGELIB
data set.</li></ol>
<p><strong>Reference information:</strong> For information about
maintaining SYS1.IMAGELIB, see >z/OS DFSMSdfp Advanced Services</a>.</p>
<h3 id="af3d">DFSMSdss:
Build the IPLable stand-alone DFSMSdss image</h3>
<p><strong>Description:</strong> If you intend to use the Stand-Alone
Services provided by DFSMSdss, you must use the DFSMSdss BUILDSA
function to create the Stand-Alone Services IPL-capable core image. Starting
with z/OS V1R12, DFSMSdss now
uses BSAM instead of EXCP to read from and write to DFSMSdss dump
data sets during DUMP, COPYDUMP, and RESTORE operations. To migrate
to this support, you must rebuild the IPL-able core image for the
Stand-Alone Services program. <a id="idx567"></a><a id="idx568"></a></p>
<p>If this migration
action is not performed, users of the DSS standalone restore will
not be able to restore backups on tape created with greater than 65520
byte blocks. Message ADRY3530I SEQUENCE ERROR ON RESTORE TAPE is issued
and the operation is terminated. Backups created with 65520 byte blocks
will restore as they did in z/OS V1R11.</p>
<table id="wq383" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to use the Stand-Alone Services
provided by DFSMSdss.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>Stand-Alone Services supports the IBM 3494 TotalStorage Enterprise Automated
Tape Library, the IBM 3495 TotalStorage Enterprise
Automated Tape Library, and the IBM 3590 TotalStorage Enterprise
Tape Subsystem.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>Stand-Alone Services does not support the creation
of the core image on an SMS-managed volume.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>
<ul>
<li>To ensure that Stand-Alone Services is available when you run
from DASD, do not delete the SYS1.ADR.SAIPLD.Vvolser data set or move
it to another volume.</li>
<li>If you IPL from DASD and later change the volume serial number,
you must rerun the BUILDSA function to create a new core image data
set with the new volume serial number in the name.</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Prepare for Stand-Alone Services by creating a Stand-Alone Services
IPLable core image with the BUILDSA command. With the BUILDSA command
you can specify the device (card reader, tape drive, or DASD volume)
from which Stand-Alone Services will be IPLed. You can also specify
the operator console to be used for Stand-Alone Services. 
<p>The BUILDSA
function builds the IPLable core image under the current operating
system and determines a record size based on whether the IPL is from
card, tape, or DASD.</p></li>
<li>Use RACF or another external
security system to protect the SYS1.ADR.SAIPLD.V<var class="pv">volser</var> data
set and the Stand-Alone Services modules.</li>
<li>If you have not done so already, make a backup copy of your system
that can be restored by this function. For information about backing
up volumes, see >z/OS DFSMSdss Storage Administration</a>.
<div>
<div class="notetitle" id="wq385">Note:</div>
<div class="notebody">Message  ADRY3530I SEQUENCE ERROR ON RESTORE TAPE might
be issued with operation terminated if a user tries to restore a back
up that was created with a block size greater than 65520 bytes, using
the DSS stand-alone restore program from z/OS V1R11.</div></div></li></ol>
<p><strong>Reference information:</strong> For more information,
see >z/OS DFSMSdfp Storage Administration</a>.</p>
<h3 id="copyvolid">DFSMSdss: Review changes to the messages that result from a
COPY or RESTORE operation with COPYVOLID</h3>
<p><strong>Description:</strong> With APAR OA36296, DFSMSdss
uses the IEEVARYD service, rather than the VARY command, to vary the
target volume offline during a COPY or RESTORE operation with either
FULL or TRACKS and the COPYVOLID parameter, when the target volume
becomes a duplicate of the source volume. As a result, the SYSLOG
no longer contains: </p>
<ul>
<li>VARY <em>device-number</em>,OFFLINE  DFSMSDSS INTERNAL
VARY</li>
<li>IEF281I <em>device-number</em> NOW OFFLINE.</li></ul><a id="idx569"></a><p class="indatacontent">Instead, the SYSLOG contains message IEF880I, as follows: </p>
<ul>
<li>IEF880I <em>device-number</em> NOW OFFLINE BY ADRSBRTN</li></ul><p class="indatacontent">Programs or procedures that rely on the presence of either the
VARY command or the IEF281I message in the SYSLOG or job logs should
be updated.</p>
<table id="wq386" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the PTF for APAR OA36296 has been applied
and you have programs or procedures that rely on the presence of either
the VARY command or the IEF281I message.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Modify your programs or procedures
to check for the new message:   </p>
<ul>
<li>IEF880I <em>device-number</em> NOW OFFLINE BY ADRSBRTN</li></ul><p class="indatacontent">This message indicates that the device has been varied offline
as the result of a DFSMSdss operation with the COPYVOLID parameter.</p>
<p><strong>Reference information:</strong> For more information
about COPY and RESTORE, refer to <cite></cite>.</p><a id="idx570"></a><a id="idx571"></a><a id="idx572"></a><a id="idx573"></a>
<h3 id="dadsmpro">	DFSMSdfp: Update operator procedures and system automation
for new DADSM pre- and post-processing dynamic exits</h3>
<p><strong>Description:</strong> Before z/OS V1R13, exits for the DADSM pre- and
post-processing functions were loaded by DFSMSdfp, as installation
exits during initialization, as modules IGGPRE00 and IGGPOST0.  Starting
with z/OS V1R13,  z/OS dynamic exits services is
used to define a pre-processing dynamic exit,  IGGPRE00_EXIT, and
a post-processing dynamic exit, IGGPOST0_EXIT, and  associate IGGPRE00
and IGGPOST0 modules as exit routines to these respective dynamic
exits. All DADSM functions (create, extend, scratch, partial release,
and rename) share these common dynamic exits and will be called where
the previous installation exits of IGGPRE00 and IGGPOST0 were called
using the same existing interfaces.  This change requires changes
to DFSMSdfp operating procedures and system automation (if any).<a id="idx574"></a></p>
<table id="wq387" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if DADSM installation exits IGGPRE00 or
IGGPOST0 are in use.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you use the IGGPRE00 or the IGGPOST0 installation exits, you
do not need to change them  in any way; just install them as you always
have. DFSMSdfp will automatically exploit the dynamic exit services
and use your IGGPRE00 or IGGPOST0 installation exit as exit routines
to the new IGGPRE00_EXIT and IGGPOST0_EXIT dynamic exits.  You do
not need to change the load module names for IGGPRE00 or IGGPOST0,
however, you may change the names if desired. If you do change the
names, update the PROG<em>xx</em> parmlib member or
issue the <span class="pk">SETPROG</span> command to get the modules loaded because
DFSMSdfp will not load them as exit routines to the dynamic exits.</li>
<li>You can now have multiple exit routines associated with each of
the IGGPRE00_EXIT and  IGGPOST0_EXIT dynamic exits for the DADSM pre-
and post-processing exits.  Other programs can use the CSVDYNEX
macro to associate their exit routines to these dynamic exits and
can add and delete exit routines from any dynamic exit routine as
required. They also can be added and deleted with the PROG<em>xx</em> member of parmlib and with the SETPROG ADD
operator command.  All exit routines will be called when the DADSM
pre- and post-dynamic exits are called from each DADSM
function.  The execution of one exit routine may then change the behavior
of a subsequent one. The order in which the exit routines are called
by the system could be in any order.</li>
<li>The IGGPRE00 and IGGPOST0 module addresses in the CVAF table (CVFDPR31,
CVFDPOR31) will continue to be set. Therefore, other programs that
continue to use this interface will be unaffected.  Since dynamic
exit services would not be used in this case, no other exit routine
associated with the dynamic exits will be called. These programs should
be changed to use dynamic exit services, CSVDYNEX.</li></ul>
<p><strong>Reference information:</strong> To read more about
the use of dynamic exit services and these new dynamic exits, see: </p>
<ul>
<li> >z/OS MVS Programming: Authorized Assembler Services Guide</a> for
information about the CSVDYNEX macro.</li>
<li> >z/OS MVS Initialization and Tuning Reference</a> for
information about the PROG<var class="pv">xx</var> parmlib member.</li>
<li> >z/OS MVS System Commands</a> for
information about the <span class="pk">D PROG</span>, <span class="pk">SETPROG EXIT</span>, and <span class="pk">SET
PROG=</span><var class="pv">xx</var> commands.</li>
<li>>z/OS DFSMS Installation Exits</a>, &quot;DFSMS
Data Management Installation/Dynamic Exits&quot; chapter.</li></ul>
<h3 id="dfpcopy">	DFSMSdfp: Update procedures that use IEBDSCPY alias name to
access IEBCOPY</h3>
<p><strong>Description:</strong> Before z/OS V1R13, the IEBCOPY utility was an APF-authorized
program that had to run from an APF-authorized library. If
another program called IEBCOPY, that program also had to be APF-authorized.
Starting in z/OS V1R13, the
IEBCOPY utility is no longer APF-authorized and can be run
from non-authorized libraries; callers of IEBCOPY no longer
need to be APF-authorized. In addition to this authorization
change, other performance improvements have been made to IEBCOPY as
well.</p>
<p>IEBCOPY is a data set library management utility that is used to
perform many critical system build and maintenance activities. If
this utility does not work correctly, then key library data sets could
be rendered as unusable and the z/OS user
would be left without a fallback method. A fallback copy of the z/OS V1R12 level of IEBCOPY is
provided, named IEBCOPYO, for use if you experience problems with
the updated version of IEBCOPY in z/OS V1R13.
 The old IEBCOPYO utility with its alias of IEBDSCPY is installed
into SYS1.LINKLIB with authorization code one, AC(1). <a id="idx575"></a></p>
<p>Since the code in IEBCOPY is now different from the code in IEBCOPYO, IBM recommends that you do not copy
and replace IEBCOPY with IEBCOPYO because of maintenance issues. <span>PTFs will update IEBCOPY and IEBCOPYO load modules appropriately
as each load module requires service.</span></p>
<p>The IEBDSCPY alias name of IEBCOPY that exists in earlier versions
of DFSMS is no longer an alias name in the z/OS DFSMS V1R13 IEBCOPY load module. The IEBDSCPY
alias name continues to exist as the alias to the IEBCOPYO load module
in z/OS V1R13, but will be
eliminated as an alias of the IEBCOPYO load module in future releases
of DFSMS.  If you currently access the IEBCOPY utility by using the
IEBDSCPY alias name, you need to make the necessary change to use
the IEBCOPY primary name.</p>
<table id="wq388" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but reommended if you don&rsquo;t want to
be connected to the pre-z/OS V1R13 version of IEBCOPY.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>It is important to note with the changes introduced
in z/OS V1R13 IEBCOPY, the
requirement for SMP/E to be APF-authorized remains. That is, these
IEBCOPY changes have no effect on the requirement that SMP/E is APF-authorized.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Programs or procedures that use the IEBDSCPY alias name to access
IEBCOPY should be changed to use the IEBCOPY primary name. Programs
that continue to use the alias name will connect to the old, pre-z/OS
V1R13 version, currently called IEBCOPYO.</li>
<li>IEBCOPY can now be called by programs that are not APF-authorized.</li></ul>
<p><strong>Reference information:</strong> For more information
about the IEBCOPY utility, see >z/OS DFSMSdfp Utilities</a>.</p>
<h3 id="evalapp">DFSMSdfp: Evaluate applications and modify for EAV enhancements</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, additional non-VSAM data set types in
the extended addressing space (EAS) are supported.  This includes
support for sequential (BASIC or LARGE), partitioned (PDS or PDSE),
Catalogs, and BDAM data sets in EAS. Before z/OS V1R12, any program trying to open one of these
types of non-VSAM data sets that have been allocated with extended
attribute DSCBs (format 8 DSCB from a z/OS V1R12
system) failed with abend IEC144I 313-0C.  Now on a z/OS V1R12 system, applications can open these non-VSAM
data sets allocated with extended attribute DSCBs with standard BSAM,
BPAM and QSAM access.</p>
<p>In many cases, application programs will function as usual.  However,
application programs that reference the data set extents found in
the DEB or access the DSCB or its extents must change to either support
format 8 DSCBs and 28-bit cylinder addressing or to abend when they
encounter such data sets.</p>
<p><a id="idx576"></a></p>
<table id="wq389" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, for application programs that allocated
the non-VSAM data sets listed above with the extended attributes option
from z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Look for applications that allocated the following types of non-VSAM
data sets in EAS with the extended attributes option from z/OS V1R11:
<ul>
<li>Sequential (BASIC or LARGE)</li>
<li>Partitioned (PDS or PDSE)</li>
<li>Catalogs</li>
<li>BDAM</li></ul>Look for applications that allocate these non-VSAM data sets
in EAS with the EATTR=OPT data set keyword on JCL or in SMS data class
to specify that the data set can have extended attribute DSCBs (format
8/9 DSCBs) and can optionally have extents in the EAS. In z/OS V1R11, the EATTR keyword would
have no affect for these non-VSAM data sets until the data set type
is enabled in the system for EAS.   However, in z/OS V1R12 these data set types are enabled for
EAS.</li>
<li>Affected applications must either support format 8 DSCBs and 28-bit
addressing or to issue an abend code to fail processing when they
encounter such data sets, because the system will no longer automatically
abend with IEC144I 313-0C.</li></ul>
<p><strong>Reference information:</strong> See also <a href="../com.ibm.zos.r13.idak100/eavr12.htm">Using extended address volumes enhancements</a> in >z/OS DFSMS Using the New Functions</a> and
information about the EAV migration assistance tracker in <a href="../com.ibm.zos.r13.idas300/migapp.htm">Using the extended address volume (EAV) migration assistance
tracker</a> in >z/OS DFSMSdfp Advanced Services</a>.</p>
<h3 id="locanyp">DFSMSdfp: Accommodate new DCBE macro option</h3>
<p><strong>Description:</strong> Before z/OS V1R12, the DCB access methods did not support
the nocapture UCB option of a dynamic allocation. Starting in z/OS V1R12, the DCB access methods
will support a new DCBE option, LOC=ANY, to signify that the application
program supports the XTIOT, UCB nocapture and DSAB-above-the-line
options of dynamic allocation. The new DCBE option also signifies
that the application program has no dependancy on any of XTIOT, UCB
address or DSAB-above-the-line options of dynamic
allocation.<a id="idx577"></a></p>
<table id="wq390" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the XTIOT, UCB nocapture and
DSAB-above-the-line options of dynamic allocation, or if any of
the callers of your program might have used those options to allocate
files which your program will open .</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Review, and modify if needed, the installation exit routines that
receive a TIOT entry or UCB address directly or indirectly.  These
include:
<ul>
<li>DADSM pre- and post-processing exits (IGGPRE00 and IGGPOST0).<a id="idx578"></a><a id="idx579"></a><a id="idx580"></a><a id="idx581"></a></li>
<li>Tape management exits (IFG019LA (label anomaly), IFG019VM (volume
mount), IFG019FV (file validation), IFG019FS (file start on volume)
and IFG055FE (file end on volume)).  They receive UCB addresses from
TEPMUCB in IFGTEP, from DEBUCBA and from TIOEFSRT.  All three sources
will allow a 31-bit UCB address.  TEPMUCB sometimes will be an uncaptured
31-bit address.  If the new DEB31UCB bit is on, the UCB address and
modeset byte will be different as described in IEZDEB.<a id="idx582"></a><a id="idx583"></a><a id="idx584"></a><a id="idx585"></a><a id="idx586"></a><a id="idx587"></a><a id="idx588"></a><a id="idx589"></a><a id="idx590"></a><a id="idx591"></a></li>
<li>NSL tape exits (NSLOHDRI, NSLEHDRI, NSLOHDRO, NSLEHDRO, NSLETRLI,
NSLETRLO, NSLCTRLO, IEFXVNSL and NSLREPOS).  OPEN, EOV and CLOSE will
always turn DEB31UCB on in the work area to signify that DXDEBUCB
is a 31-bit UCB address and the modeset byte is moved as described
above.  Even though the UCB address field will be four bytes, it typically
will still contain a three-byte address.<a id="idx592"></a><a id="idx593"></a><a id="idx594"></a><a id="idx595"></a><a id="idx596"></a><a id="idx597"></a><a id="idx598"></a><a id="idx599"></a><a id="idx600"></a><a id="idx601"></a><a id="idx602"></a><a id="idx603"></a><a id="idx604"></a><a id="idx605"></a><a id="idx606"></a><a id="idx607"></a><a id="idx608"></a><a id="idx609"></a></li>
<li>Volume label editor routines (IFG0193C and IFG0553C).  Same work
area changes as described for the NSL routines.<a id="idx610"></a><a id="idx611"></a><a id="idx612"></a><a id="idx613"></a></li>
<li>DCB OPEN installation exit (IFG0EX0B).<a id="idx614"></a><a id="idx615"></a></li>
<li>The IGXMSGEX installation exit for the MSGDISP macro already supports
its caller passing a 31-bit UCB address but there might be more cases
in which this occurs.<a id="idx616"></a><a id="idx617"></a></li>
<li>The data management ABEND installation exit (IFG0199I) passes
a UCB address in field OAIXUCBA.  It might now be 31-bit.<a id="idx618"></a><a id="idx619"></a></li>
<li>IECIEUCB as mapped by the IECIEPRM macro for the ISO/ANSI Version
3 and Version 4 installation exits (IFG0193G) contains the tape UCB
address.  In the past this has always been a 24-bit address.  Now
it might be a 31-bit address.<a id="idx620"></a><a id="idx621"></a></li></ul> 
<p>The above exits are documented in >z/OS DFSMS Installation Exits</a>.
 IEFDB401, a dynamic allocation input validation exit, is documented
in >z/OS MVS Installation Exits</a>.</p></li>
<li>Verify that the installation exit routines will not be affected
adversely.</li>
<li>Set the NON_VSAM_XTIOT option to YES or NO in the DEVSUP<var class="pv">xx</var> parmlib
member. (The default is NON_VSAM_XTIOT=NO.)</li>
<li>Change the program to set LOC=ANY in the DCBE macro. The default
is LOC=BELOW. 
<div>
<div class="notetitle" id="wq392">Note:</div>
<div class="notebody">The new DCBELOCANY flag can only be used in z/OS V1R12 or later. If a program
has the DCBELOCANY flag defined, and is compiled or assembled using
a z/OS V1R11 level of the DFSMS
macros, then a compile or assemble error will occur. See APAR OA33409
for more information.</div></div></li></ol>
<p><strong>Reference information:</strong> For details about
the new DCBE option, see >z/OS DFSMS Macro Instructions for Data Sets</a> and >z/OS DFSMS Using the New Functions</a>.</p><a id="idx622"></a><a id="idx623"></a>
<h3 id="recmlnk">DFSMSdss: Recompile and link-edit exit routines or applications
that change options in the ADRUFO block</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, if you change options in the ADRUFO
block with either:</p>
<ul>
<li>the options installation exit routine, ADRUIXIT, or</li>
<li>an application that invokes DFSMSdss with the API or XMAPI and
then uses the Presenting ADRUFO Record exit (Eioption exit 13),</li></ul><p class="indatacontent">you must recompile and link-edit the exit routine or application
using macro libraries provided with z/OS V1R12. <a id="idx624"></a></p>
<table id="wq393" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you change options in the ADRUFO block
with either the exit routine or application.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Recompile and link-edit the
exit routine or application using macro libraries provided with release z/OS V1R12.</p>
<p><strong>Reference information:</strong> For details, see >z/OS DFSMS Installation Exits</a>.</p>
<h3 id="modiobs">DFSMSdss: Modify applications to handle larger I/O buffers</h3><a id="idx625"></a><a id="idx626"></a><a id="idx627"></a><a id="idx628"></a>
<p><strong>Description:</strong> Starting with z/OS V1R12, DFSMSdss uses BSAM instead of EXCP to
read from and write to DFSMSdss dump data sets during DUMP, COPYDUMP,
and RESTORE operations. This allows DFSMSdss to support 256K blocksize
when writing to and reading from a tape. Before z/OS V1R12, the maximum was 65,520 bytes. If you
have an application that invokes DFSMSdss with the API or XMAPI, you
should ensure that the application handles I/O buffers up to the new
maximum of 262,144 bytes. The affected exit options are EIOP03 and
EIOP06. For these exits, the storage (buffer) pointed to by EIRECPTR
may now be greater than 65,520 bytes, up to a maximum of 262,144 bytes.<a id="idx629"></a><a id="idx630"></a><a id="idx631"></a><a id="idx632"></a></p>
<table id="wq394" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the application invokes DFSMSdss with
the API or XMAPI.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>
<div>
<div class="notetitle" id="wq395">Note:</div>
<div class="notebody"> Tapes with greater than 65,520
bytes BLKSIZE can be read by z/OS V1R11
systems with the PTFs for APAR OA30822 installed. <span>If
you try to restore from a tape that has greater than 64K blocksize,
but do not have the PTFs for OA30822 installed on your system, the
restore will fail. Most likely, it will fail with an ADR370E INVALID
SEQUENCE NUMBER error message.</span></div></div></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Ensure that the application can handle I/O buffers that are up
to 262,144 bytes. If the application cannot handle I/O buffers that
are up to 262,144 bytes, you can:
<ul>
<li>Specify PARM='USEEXCP=YES' in OPTPTR of the API or the EXEC PARM
with PGM=ADRDSSU (for example, EXEC PGM=ADRDSSU,PARM='USEEXCP=YES'). You
can also specify PARM='USEEXCP=YES' in OPTPTR of the API that invokes
ADRXMAIA, or specify it on the EXEC PARM with PGM=ADRXMAIA (for example,
EXEC PGM=ADRXMAIA,PARM='USEEXCP=YES'). </li>
<li>Set a block size to an acceptable value either with the JCL DD
statement or when dynamically allocating the DD for your application
during processing of the Presenting ADRUFO Record exit (Eioption exit
13).</li>
<li>Code BLKSZLIM and set the BLKSZLIM value to 65,520. Note that
DSS only supports BLKSZLIM of 65,520 and above; for a backup to be
compatible with releases earlier than z/OS V1R10,
the backup must have no larger than 65,520 byte blocks. BLKSZLIM can
be set in the following places:
<ol type="1">
<li>BLKSZLIM keyword on the DD statement or dynamic allocation. The
BLKSZLIM keyword on a DD statement keyword is described in >z/OS MVS JCL Reference</a>.</li>
<li>Block size limit in data class. Set by storage administrator.
Available even if the data set is not SMS-managed. The block
size in the data class is described in >z/OS DFSMS Implementing System-Managed Storage</a>.</li>
<li>System default set in TAPEBLKSZLIM keyword in DEVSUP<em>xx</em> parmlib member in SYS1.PARMLIB. Also available
in DFA. The TAPEBLKSZLIM parameter is described in >z/OS MVS Initialization and Tuning Reference</a>.</li></ol></li></ul></li>
<li>If the application inspects the DTVBLKSZ field in the volume record
of physical dumps or the DTHBLKSZ field in the data set header of
logical dumps, you may need to make further changes. When a physical
backup is created on tape with a block size that is greater than 65,520
bytes, the DTVBLKSZ field is <span class="hex">X'FFFE'</span>. The block size is stored
in an extended volume record following the volume record, DTSDEVOL.
When a logical backup is created on tape with a block size greater
than 65,520 bytes, the DTHBLKSZ field is <span class="hex">X'FFFE'</span>. The block
size is stored in a new extended tape header record, S, following
the data set header record.</li></ul>
<div>
<div class="notetitle" id="wq397">Note:</div>
<div class="notebody"> You need to apply the PTF of DFSMSdss APAR OA35349
to avoid the ABEND002-030 problem during the RESTORE and COPYDUMP
opertaion from either a standard label tape with a blocksize of zero
in the tape label or a non label tape. If you have created DUMP or
COPYDUMP data sets in z/OS V1R7
or earlier systems and you do not apply the APAR, the BLKSIZE in tape
SL header contains zero ( 0 ). For details, see the documentation
for APAR OA13742.</div></div>
<p><strong>Reference information:</strong> For information about
the API, see >z/OS DFSMSdss Storage Administration</a>.
For information about the Presenting ADRUFO Record exit  (Eioption
exit 13) , see >z/OS DFSMS Installation Exits</a>.</p>
<h3 id="hsmpdatr">DFSMShsm: Accommodate the changed default of PDA trace during
DFSMShsm startup</h3>
<p><strong>Description:</strong> Before z/OS V1R13, PDA trace was disabled (PDA=NO) during
DFSMShsm startup unless PDA=YES was <em>manually</em> added
to the DFSMShsm startup procedure. Starting with z/OS V1R13, PDA trace is enabled (PDA=YES) by default
during DFSMShsm startup. After DFSMShsm is started, the SETSYS PDA
setting controls PDA tracing.<a id="idx633"></a><a id="idx634"></a><a id="idx635"></a><a id="idx636"></a></p>
<table id="wq398" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want the new default.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To enable PDA trace during
DFSMShsm startup, no action is required. To disable PDA trace during
DFSMShsm startup, specify PDA=NO in the DFSMShsm startup procedure
before starting DFSMShsm.</p>
<div>
<div class="notetitle" id="wq399">Note:</div>
<div class="notebody">When you do not allocate the ARCPDOX and ARCPDOY data
sets in the DFSMShsm start procedure, you receive the following message
during initialization unless PDA=NO is explicitly specified. 
<pre class="xmp"><code>ARC0036E I/O [INHIBITED | DISABLED] FOR DFSMSHSM PROBLEM DETERMINATION 
  OUTPUT DATA SET, REAS=<var class="pv">reason-code</var></code></pre>Even in this situation,
HSM continues to initialize and operate.</div></div>
<p><strong>Reference information:</strong> For more information
about enabling or disabling PDA trace during DFSMShsm startup, see >z/OS DFSMShsm Implementation and Customization Guide</a>.</p>
<h3 id="hsmdsrec">DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION command
DATASETRECOVERY parameter default</h3>
<p><strong>Description:</strong> Before z/OS V1R13, the <span class="pk">SETSYS FASTREPLICATION</span> command
DATASETRECOVERY parameter default was PREFERRED and fast replication
data set recovery was performed whenever possible. The standard copy
method was used when fast replication could not be. Starting with z/OS V1R13, the <span class="pk">SETSYS FASTREPLICATION</span> command
DATASETRECOVERY parameter default is changed to NONE and the standard
copy method is used to perform data set recovery. Fast replication
is not used by default.<a id="idx637"></a><a id="idx638"></a><a id="idx639"></a><a id="idx640"></a><a id="idx641"></a><a id="idx642"></a><a id="idx643"></a><a id="idx644"></a><a id="idx645"></a></p>
<table id="wq400" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to use fast replication for
data set recovery and you do not currently specify a fast replication
data set recovery preference in the ARCCMD<em>xx</em> parmlib
member of SYS1.PARMLIB.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Determine which fast replication data set recovery preference
you want to use.</li>
<li>Add a fast replication data set recovery preference to the ARCCMD<em>xx</em> parmlib member of SYS1.PARMLIB.
<ul>
<li>If a fast replication data set recovery preference is specified
and matches the preference you want to use, no action is required.</li>
<li>If no fast replication data set recovery preference is specified,
add <span class="pk">SETSYS FASTREPLICATION (DATASETRECOVERY (PREFERRED))</span> to
continue using the same preference as before z/OS V1R13.</li></ul>Alternatively, if your preference is to require fast replication
data set recovery, you can specify <span class="pk">SETSYS FASTREPLICATION (DATASETRECOVERY
(REQUIRED))</span>.</li></ol>
<div>
<div class="notelisttitle" id="wq402">Notes:</div>
<ol type="1">
<li>If you previously specified <span class="pk">SETSYS FASTREPLICATION (DATASETRECOVERY
(NONE))</span> in the ARCCMD<em>xx</em> parmlib member
of SYS1.PARMLIB, you can optionally remove it and use the default.</li>
<li>The<span class="pk"> FRRECOV</span> command ALLOWPPRCP options PRESERVEMIRRORREQUIRED,
PRESERVEMIRRORPREFERRED, PRESERVEMIRRORNO, and YES cannot be used
if fast replication data set recovery is not allowed. That is, if
the z/OS V1R13 <span class="pk">SETSYS FASTREPLICATION</span> command
DATASETRECOVERY parameter default is used or if <span class="pk">SETSYS FASTREPLICATION
(DATASETRECOVERY (NONE))</span> setting is in effect.</li>
</ol></div>
<p><strong>Reference information:</strong> For more information
about fast replication, the <span class="pk">FRRECOV</span> command, and the <span class="pk">SETSYS</span> command,
see >z/OS DFSMShsm Storage Administration</a>.</p>
<h3 id="hsmarc180">DFSMShsm: Replace user-defined patch with new SETSYS FASTREPLICATION
command to enable ARC1809I messages</h3>
<p><strong>Description:</strong> Before z/OS V1R13, a patch was required to enable (and
subsequently disable) ARC1809I messages during fast replication volume
pairing. Starting with z/OS V1R13,
the VOLUMEPAIRMESSAGES parameter is added to the existing <span class="pk">SETSYS
FASTREPLICATION</span> command to control the issuance of the ARC1809I
messages. Remove the patch and replace it with the new parameter. <a id="idx646"></a><a id="idx647"></a><a id="idx648"></a><a id="idx649"></a><a id="idx650"></a><a id="idx651"></a><a id="idx652"></a></p>
<table id="wq404" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the ARCCMD<em>xx</em> parmlib
member of SYS1.PARMLIB contains: <samp class="xph">PATCH .FRGCB.+9 BITS(.1......)</samp></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>
<div class="lines">The <span class="pk">SETSYS FASTREPLICATION</span><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="pk">(VOLUMEPAIRMESSAGES(YES))</span><br />
statement in ARCCMC<var class="pv">xx</var> is not supported<br />
on pre-z/OS V1R13 systems.<br />
</div></td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Remove <samp class="xph">PATCH .FRGCB.+9 BITS(.1......)</samp> from the ARCCMD<em>xx</em> parmlib member of SYS1.PARMLIB.</li>
<li>Add <span class="pk">SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES))</span> to
the ARCCMD<em>xx</em> parmlib member of SYS1.PARMLIB.</li></ol>
<p><strong>Reference information:</strong> For more information
about using the <span class="pk">SETSYS FASTREPLICATION</span> command and VOLUMEPAIRMESSAGES
parameter to disable unwanted ARC1809I messages, see >z/OS DFSMShsm Storage Administration</a>.</p>
<h3 id="hsmmsgie">DFSMShsm: Review messages changed from I (informational) to
E (eventual action) type</h3>
<p><strong>Description:</strong> Before z/OS V1R13, messages ARC0036, ARC0503, and ARC0704
were <em>informational</em> messages (ending in the
letter &quot;I&quot;). Starting with z/OS V1R13,
messages ARC0036, ARC0503, and ARC0704 are reclassified as <em>eventual action</em> messages (ending in the letter &quot;E&quot;).
The meaning of the messages is unchanged. The type is changed only.</p>
<p>Each of these messages indicate a significant error has occurred
and are more easily identifiable as eventual action messages.</p>
<ul>
<li>Message ARC0036E indicates that an I/O error occurred when writing
to the PDA output data set.</li>
<li>Message ARC0503E indicates a dynamic allocation error.</li>
<li>Message ARC0704E indicates a VTOC copy data set processing error
during volume backup, dump, or recovery.</li></ul><p class="indatacontent">These changes can affect applications that depend on message
ARC0036I, ARC0503I, or ARC0704I and applications triggered by message
type.<a id="idx653"></a><a id="idx654"></a><a id="idx655"></a><a id="idx656"></a><a id="idx657"></a><a id="idx658"></a><a id="idx659"></a><a id="idx660"></a><a id="idx661"></a></p>
<table id="wq406" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your applications depend on message
ARC0036I, ARC0503I, or ARC0704I or if your applications are triggered
by message type.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update applications that do
the following:</p>
<ul>
<li>Depend on ARC0036I to work with ARC0036E.</li>
<li>Depend on ARC0503I to work with ARC0503E.</li>
<li>Depend on ARC0704I to work with ARC0704E.</li>
<li>Are triggered by message type.</li></ul>
<p><strong>Reference information:</strong> For more information
about DFSMShsm messages, see >z/OS MVS System Messages, Vol 2 (ARC-ASA)</a>.</p>
<h3 id="ptchmcvt">DFSMShsm: Remove patch that prevents SMS MVT chain rebuild</h3>
<p><strong>Description:</strong> Before z/OS V1R13, the flag at MCVT+C8 X'80' was used to
prevent the SMS MVT chain rebuild at the beginning of primary space
management and at the beginning of interval migration, based on the
current SMS storage group definitions. If the SMS storage groups had
not been changed and no new SMS volumes had been added since the last
time primary space management or interval migration was run, you could
prevent the SMS MVT chain from being needlessly rebuilt or refreshed
by entering the following PATCH command:</p>
<p><span class="pk">PATCH .MCVT.+C8 BITS(1.......)</span></p>
<p>Starting with z/OS V1R13,
this flag is maintained automatically by DFSMShsm. DFSMShsm checks
for the occurrence of an ENF 15 event at the beginning of primary
space management, at the beginning of interval migration, and at the
beginning of on-demand migration. When an ENF 15 event is reported,
DFSMShsm performs an SMS MVT chain rebuild or refresh. After a successful
SMS MVT chain rebuild, DFSMShsm does not rebuild or refresh the MVT
chain until the next SMS configuration change (that is, the next ENF
15 event).</p>
<p>Starting with z/OS V1R13,
DFSMShsm does not take into account the <span class="pk">PATCH .MCVT.+C8 BITS(1.......)</span> command.
Nevertheless,  it is recommended to remove this patch command from
the ARCCMD<var class="pv">xx</var> parmlib member of SYS1.PARMLIB to avoid any
misunderstanding.<a id="idx662"></a><a id="idx663"></a><a id="idx664"></a><a id="idx665"></a><a id="idx666"></a><a id="idx667"></a><a id="idx668"></a><a id="idx669"></a></p>
<table id="wq407" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMS.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because starting from z/OS V1R13, the patch command no
longer performs a useful function other than what is already handled
automatically by DFSMShsm. Additionally, it been discovered in the
past that leaving unnecessary useless patches in DFSMShsm's startup
procedures can cause confusion and potential problems.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Remove this patch when all systems are at z/OS V1R13 if a common DFSMShsm's
startup procedure is shared with downlevel systems.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Remove <span class="pk">PATCH .MCVT.+C8
BITS(1.......)</span> from the ARCCMD<var class="pv">xx</var> parmlib member of SYS1.PARMLIB.</p>
<p><strong>Reference information:</strong> None.</p>
<h3 id="multicds">DFSMShsm: Update operator procedure in the Multicluster CDS
environment</h3>
<p><strong>Description:</strong> In the DFSMShsm Multicluster
control data sets environment, the same number of clusters must be
specified to all DFSMShsm hosts that are sharing a multicluster MCDS
or BCDS, or both. If a DFSMShsm host is started with a different number
of clusters than the other currently active hosts, the CDS will be
logically corrupted and may require extensive recovery actions.</p>
<p>In z/OS V1R12 <span>(and
in z/OS V1R11, z/OS V1R10, and z/OS V1R9 when the PTF for OA29346 is installed)</span>,
DFSMShsm is modified to detect a conflict between the number of CDS
clusters specified to a host in the startup proclib JCL and the number
recorded in the MHCR record.<a id="idx670"></a></p>
<table id="wq408" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
(z/OS V1R11, z/OS V1R10, and z/OS V1R9
by APAR OA29346).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without the PTF for APAR OA29346 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the DFSMShsm Multicluster CDS
environment.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> A new WTOR message, ARC0264A,
is issued asking if the change to the cluster number is intended.
If the reply is Y, the DFSMShsm host is allowed to start with the
new cluster count. If the reply is N, the DFSMShsm host is not allowed
to start, which results in error message ARC0130I RC20.</p>
<pre class="xmp"><code>ARC0264A {MCDS|BCDS} CLUSTERS CHANGED FROM m TO d. IF NOT INTENDED,
         STARTUP WILL RESULT IN CDS CORRUPTION. INTENDED? (Y OR N)
ARC0130I CONTROL DATA SET DEFINITION RULES FOR THE {MCDS|BCDS} WERE NOT FOLLOWED,
         RETURN CODE=20</code></pre><p class="indatacontent">The WTOR message is issued at the first
DFSMShsm host initialization right after switching into the multicluster
CDS environment.</p>
<div>
<div class="notetitle" id="wq409">Note:</div>
<div class="notebody">Regardless of the single or multiple
DFSMShsm host environment, the initialization of the first host after
the number of CDS clusters has been updated by the reorganization
will result in an ARC0264A WTOR message asking the operator to confirm
the new cluster count.</div></div>
<p><strong>Reference information:</strong> For more information
about the Multicluster Control Data Sets, see >z/OS DFSMShsm Implementation and Customization Guide</a>.</p>
<h3 id="hsmdsscrsmem">DFSMShsm: Remove user-defined patch that disables or enables
use of the DFSMSdss cross memory API</h3>
<p><strong>Description:</strong>  In z/OS V1R10 and later, DFSMShsm's use of the DFSMSdss
cross memory API can be disabled or enabled by including a patch or
the <span class="pk">SETSYS DSSXMMODE (Y | N)</span> command in the ARCCMD<var class="pv">xx</var> parmlib
member of SYS1.PARMLIB. Starting with z/OS V1R12
, support is added to the existing <span class="pk">SETSYS DSSXMMODE</span> command
to permit the <strong>Y</strong> and <strong>N</strong> setting
to individually control backup, CDS backup, dump, migration, full-volume
recovery, and data set recovery. Because of this, disabling or enabling
DFSMSdss cross memory mode should be done exclusively with the <span class="pk">SETSYS
DSSXMMODE</span> command. Instances of patching the MCVT at offset +433
should be removed from ARCCMD<var class="pv">xx</var>.</p><a id="idx671"></a><a id="idx672"></a><a id="idx673"></a><a id="idx674"></a>
<table id="wq410" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the ARCCMD<var class="pv">xx</var> parmlib member
of SYS1.PARMLIB contains: <samp class="xph">PATCH .MCVT.+433</samp></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Remove <samp class="xph">PATCH .MCVT.+433</samp> from the ARCCMD<var class="pv">xx</var> parmlib
member of SYS1.PARMLIB.</li>
<li>Add the corresponding SETSYS DSSXMMODE command in the ARCCMD<var class="pv">xx</var> parmlib
member of SYS1.PARMLIB.</li></ol>
<p><strong>Reference information:</strong> For more information
about using the SETSYS DSSXMMODE command, see >z/OS DFSMShsm Storage Administration</a>.</p>
<h3 id="hsmdssaddr">DFSMShsm: Configure your security system to permit started
procedures using new address space identifier</h3>
<p><strong>Description:</strong> Before z/OS V1R12, when using the DFSMSdss cross memory
API, the address space identifier for full-volume and data
set recovery from dump was ARC<var class="pv">n</var>REST. <span>Starting
in z/OS V1R12, when using the
DFSMSdss cross memory API, the address space identifier for full-volume
recovery from dump is changed to ARC<var class="pv">n</var>RST<var class="pv">y</var> where <var class="pv">n</var> is
the DFSMShsm host ID and <var class="pv">y</var> is the instance of the DFSMSdss
started task (a number 1 - 4).</span> Data set recovery from dump will
still use ARC<var class="pv">n</var>REST.</p>
<p>With the addition of multitasking volume recovery from DUMP in z/OS V1R12, the address space names
for the DSS cross memory address spaces are separated so that four
DSS volume recovery address spaces and only one DSS data set recovery
address space can be created. ARC<var class="pv">n</var>REST is used for data set
recovery from dump; ARC<var class="pv">n</var>RST<var class="pv">y</var> is used for volume
recovery from dump</p><a id="idx675"></a><a id="idx676"></a><a id="idx677"></a><a id="idx678"></a><a id="idx679"></a>
<table id="wq412" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if DFSMSdss cross memory support is used
for full-volume recovery from dump.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Before attempting full-volume
recovery from dump, configure your security system to permit started
procedures using the new address space identifier for DFSMSdss cross
memory support for full-volume recovery from dump.</p>
<p><strong>Reference information:</strong> For more information
about controlling use of DFSMSdss cross memory support using the SETSYS
DSSXMMODE command, see >z/OS DFSMShsm Storage Administration</a>. For more information
about DFSMSdss address spaces started by DFSMShsm and configuring
your security system, see >z/OS DFSMShsm Implementation and Customization Guide</a>.</p>
<h3 id="r12hsmquery">DFSMShsm: Update applications that depend on QUERY COPYPOOL
output</h3>
<p><strong>Description:</strong> Before z/OS V1R12, the DFSMShsm QUERY COPYPOOL command
output did not display FlashCopy&reg; &quot;background
copy percent-complete&quot; information. Starting in z/OS V1R12, the QUERY COPYPOOL
command output in message ARC1820I will display applicable &quot;background
copy percent-complete&quot; (PCT-COMP) information for
full-volume FlashCopy pairs
with an incomplete background copy. Percent-complete information (a
percentage) is available for full-volume FlashCopy pairs with an incomplete background copy
only. A full-volume FlashCopy relationship
is established when the FlashCopy technique
(such as fast reverse restore or incremental) designates it, or when
SETSYS FASTREPLICATION(FCRELATION(FULL)) has been specified.</p>
<p>This change can affect applications that depend on QUERY COPYPOOL
output.</p><a id="idx680"></a><a id="idx681"></a><a id="idx682"></a><a id="idx683"></a><a id="idx684"></a><a id="idx685"></a>
<table id="wq413" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you will be using any FlashCopy technique that creates
a full-volume FlashCopy relationship
or if you will be specifying SETSYS FASTREPLICATION(FCRELATION(FULL))
and your applications depend on QUERY COPYPOOL output or message ARC1820I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update applications that depend
on QUERY COPYPOOL output.</p>
<p><strong>Reference information:</strong> For more information
about using the QUERY command, see >z/OS DFSMShsm Storage Administration</a>.</p>
<h3 id="r12hsmlist">DFSMShsm: Update applications that depend on LIST command output</h3>
<p><strong>Description:</strong> The DFSMShsm LIST command output
changed in z/OS V1R11 and in z/OS V1R12.</p>
<ul>
<li>Starting in z/OS V1R11,
the LIST DSNAME(<em>dsname</em>) BCDS and LIST LEVEL(<em>hlq</em>) BCDS output no longer display the RACF IND field when OUTDATASET
or SYSOUT (default) is specified as the destination for the output. The RACF IND field is displayed when
TERMINAL is specified as the destination for the output.</li>
<li>Starting in z/OS V1R12,
the LIST COPYPOOL(<em>cpname</em>) output includes:
a new FASTREPLICATION state (FCFRRINCOMPLETE), fast reverse restore
status field (FCFRR=), and recovery complete status field (RECOVERYINCOMPLETE=).
This new output is displayed when OUTDATASET, SYSOUT (default), or
TERMINAL is specified as the destination for the output.</li></ul>
<p>These changes can affect applications that depend on LIST output.</p><a id="idx686"></a><a id="idx687"></a><a id="idx688"></a><a id="idx689"></a><a id="idx690"></a>
<table id="wq414" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
and z/OS V1R11 (as explained
in the description).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your applications depend on the RACF IND field value in the output
with the OUTDATASET or SYSOUT destination, or if your applications
depend on LIST COPYPOOL(<em>cpname</em>) output.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Remove any dependency on the RACF IND
field on the LIST DSNAME(<em>dsname</em>) BCDS or LIST
LEVEL(<em>hlq</em>) BCDS output when using OUTDATASET
or SYSOUT.</li>
<li>Update applications that depend on LIST COPYPOOL(<em>cpname</em>)
output to handle the new FASTREPLICATION state and new fields.</li></ol>
<p><strong>Reference information:</strong> See <a href="../com.ibm.zos.r13.arcf000/hr1036.htm">Using the LIST Command</a> in >z/OS DFSMShsm Storage Administration</a>.</p><a id="idx691"></a><a id="idx692"></a>
<h3 id="hsmarcb">DFSMShsm: Accommodate the change of ARCBDEXT exit</h3>
<p><strong>Description:</strong> Prior to DFSMShsm z/OS V1R10, ARCBDEXT was called
during volume-level backup operations (AUTOBACKUP for automatic and
BACKVOL for command-based operations).  Users examined information
in the exit's input data structure to determine whether to allow
or disallow backup of a data set. Starting with DFSMShsm z/OS V1R10, ARCBDEXT is called
during individual data set backup operations, as well as volume-level
backup operations. When called for individual data set backup, the
exit's input data structure differs, but the return code values
and meanings remain the same as for volume-level backups. Users
must examine the level information in the input data structure, at
offset x'04' , to determine whether ARCBDEXT is being  invoked for
 volume-level or for individual data set backup. <a id="idx693"></a></p>
<table id="wq416" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11
by APAR OA28948 and z/OS V1R10
by APAR OA28136.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without APAR OA28948.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to allow command backup but
disallow autobackup for some data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong>  Examine the level information
in the input data structure at offset x'04' to determine whether ARCBDEXT
is being  invoked for volume-level or for individual data set
backup. The level field will contain '*EXPAND1' for  volume-level
requests and '*EXPAND2' for individual data set backup requests. For
individual data set backup requests, the field at offset x'0C' contains
additional status information about whether the backup request is
the result of a backup data set command or the result of retry from
a volume command.</p>
<p><strong>Reference information:</strong> For more information,
see >z/OS DFSMS Installation Exits</a>.</p>
<h2 id="wq417">DFSMS actions
to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes DFSMS migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx694"></a><a id="idx695"></a><a id="idx696"></a><a id="idx697"></a><a id="idx698"></a><a id="idx699"></a>
<h3 id="armode64">DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement
in DFSMS macros</h3>
<p><strong>Description:</strong> Before z/OS V1R13, many DFSMS macros that did not support
64-bit or AR mode did not react to being invoked in 64-bit
or AR mode, and generated code that might have been invalid in 64-bit
or AR mode. Starting with z/OS V1R13,
these macros are changed to issue an assembly-time message and suppress
expansion if they are invoked in 64-bit or AR mode. If you
have code, including exits, that invokes DFSMS macros, you should
review your code and modify it as appropriate to accommodate the new
enforcement of 64-bit and AR mode rules.<a id="idx700"></a><a id="idx701"></a></p>
<table id="wq418" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have code, including exits, that
invokes DFSMS macros.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Modify your source code so
that no DFSMS macros are invoked after the SYSSTATE macro specifies
64-bit or AR mode. (The one exception is the TRKADDR macro, which
supports 64-bit mode.) When you assemble your code, if a return
code of 8 or greater is returned by the High Level Assembler, check
for assembler messages that indicate that a macro has been invoked
after AMODE 64 or AR mode was specified on the SYSSTATE macro.</p>
<p>Change the source code as appropriate:</p>
<ul>
<li>If the macro invocation will be executing in a supported environment
(31-bit or 24-bit and not AR mode), then precede that invocation with
SYSSTATE AMODE64=NO,ASCENV=P.</li>
<li>If your tests show that the macro expansion does work when invoked
in 64-bit or AR mode, then you can consider coding SYSSTATE with AMODE64=NO
and ASCENV=P even though it does not match the execution environment.
 This type of macro invocation is not supported by IBM unless the documentation for that macro says
otherwise.</li></ul>
<p><strong>Reference information:</strong> For details about
DFSMS macros, refer to >z/OS DFSMS Macro Instructions for Data Sets</a> and >z/OS DFSMSdfp Advanced Services</a>.</p>
<h3 id="oamconf">DFSMSdfp: Run OAM configuration database migration job</h3>
<p><strong>Description:</strong> When migrating to z/OS V1R13, you must run the OAM
configuration database migration job (CBRSMR1D). CBRSMR1D creates
the File System Delete Table in the OAM Configuration Database. If
you use OAM object support, you must run CBRSMR1D even if you do not
plan to use OAM file system support. <a id="idx702"></a><a id="idx703"></a></p>
<table id="wq419" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use OAM object support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>If you use OAM object support, you must run CBRSMR1D even if you
do not plan to use OAM file system support. Update and run the OAM
configuration database migration job (CBRSMR1D) provided in SAMPLIB.</li>
<li>Run OAM DB2 BIND and GRANT
jobs. To determine which BIND and GRANT jobs you need to run, see >z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</a>.</li></ol>
<p><strong>Reference information:</strong> For more information,
see the topic &quot;<a href="../com.ibm.zos.r13.idao200/install.htm">Migrating, Installing, and Customizing OAM</a>&quot; in >z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</a>.</p>
<h3 id="bindgra">DFSMSdfp:
Run OAM DB2 BIND jobs</h3>
<p><strong>Description:</strong> When migrating to any new release
of z/OS, you must run OAM DB2 BIND jobs if you are using OAM
for object support. The BIND jobs update DB2 with
new OAM DB2 code.</p><a id="idx704"></a><a id="idx705"></a><a id="idx706"></a>
<table id="wq421" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use OAM object support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Run the BIND jobs appropriate
to your installation:</p>
<ol type="1">
<li>Update and execute the samplib job CBRPBIND (OAM DB2 Bind Package Job).</li>
<li>Do one of the following:
<ul>
<li>If your installation starts OAM, uses the file system
sublevel or optical or tape devices, or uses the OAM storage management
component (OSMC), do the following:
<ul>
<li>Update and execute samplib job CBRABIND (OAM DB2 Application Plan Bind for LCS and OSR).</li>
<li>Update and execute samplib job CBRHBIND (OAM DB2 Application Plan Bind for OSMC).</li></ul></li>
<li>If your installation does not start OAM, use the file
system sublevel or optical or tape devices, or use OSMC, update and
execute samplib job CBRIBIND (OAM DB2 Application
Plan Bind for OSR only).</li></ul></li>
<li>For more information, see the topic &quot;<a href="../com.ibm.zos.r13.idao200/install.htm">Migrating, Installing, and
Customizing OAM</a>&quot; in >z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</a>.</li></ol><p class="indatacontent"> </p>
<div>
<div class="notetitle" id="wq423">Note:</div>
<div class="notebody">If you choose to edit a previous version of
an OAM BIND job, you must incorporate any new changes as described
in the header of each samplib OAM BIND job.</div></div>
<p><strong>Reference information:</strong> For more information
about OAM, see >z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</a>.</p>
<h3 id="useindz">DFSMSdfp:
Use indirect zFS file system data set catalog support</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, zFS file systems may be cataloged using
a system symbol. This allows zFS file system data sets to be indirectly
cataloged the same way as non-VSAM data sets.</p><a id="idx707"></a>
<table id="wq424" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to make deployment easier
for zFS file system data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Systems prior to z/OS V1R12
cannot process the indirectly-cataloged zFS file system data
sets and will fail with volume not found errors.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>This support is limited to zFS file system data
sets only. That is, all VSAM linear data sets are not included in
this support; only data sets formatted as zFS file systems are included
in this support. Also, this support is limited to single-volume zFS
file system data sets.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use the reference information
below to use this new support.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For setting up the indirect catalog entry, see &quot;Define
Cluster&quot; in >z/OS DFSMS Access Method Services for Catalogs</a> and
DOC APAR OA34695.</li>
<li>For information about the steps required to establish an indirect
catalog entry for zFS file system data sets and what the IDCAMS LISTCAT
output will produce, see >z/OS DFSMS Access Method Services for Catalogs</a>.</li>
<li>For cloning processes to use this support, see >z/OS Planning for Installation</a>.</li></ul>
<h3 id="csichng">DFSMSdss: Accommodate Catalog Search Interface default change</h3>
<p><strong>Description:</strong> In z/OS V1R11, DFSMSdss logical data set COPY, DUMP,
and RELEASE operation used the Catalog Search Interface (CSI) by default
to find cataloged data sets based on the generic filter criteria on
the INCLUDE keyword when no input volumes are specified. Prior to z/OS V1R11, you could make use
of CSI functionality on z/OS V1R10, z/OS V1R9, and z/OS V1R8 systems by installing the PTF for APAR
OA25644 and patching the offset X'54' into the ADRPATCH module to
X'11'.</p>
<p>In z/OS V1R13 (and with
the PTF for APAR OA32120 installed on z/OS V1R12
and z/OS V1R11), DFSMSdss no
longer uses the CSI for Catalog filtering during logical data set
processing as the default; DFSMSdss uses generic catalog locates in
this scenario.<a id="idx708"></a><a id="idx709"></a><a id="idx710"></a></p>
<p></p>
<table id="wq425" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(z/OS V1R12 and z/OS V1R11 by APAR OA32120).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11, both without
the PTF for APAR OA32120 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to use CSI during Catalog filtering
for logical data set processing.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>To use the CSI during Catalog filtering for the DFSMSdss logical
data set COPY, DUMP, and RELEASE operation, the DFSMSdss patch byte
at offset X'54' must be set to X'11' to enable the functionality.</li>
<li>If the DFSMSdss patch byte at offset X'54' is set to any value
other than X'00' and X'11' to use generic catalog locates instead
of CSI (as done in earlier releases), you do not need to set it because
this previous method of finding cataloged data sets is now in effect
by default.</li></ul>
<div>
<div class="notetitle" id="wq426">Note:</div>
<div class="notebody">If you are intentionally using the CSI default
by setting the DFSMSdss PATCH byte at offset X'54' to X'11', then
you don't need to take any action to expect the functionality be effective.
However, if you left the DFSMSdss PATCH byte at offset X'54' as X'00'
and want to continue using the CSI during Logical Data Set processing,
you need to set that Patch byte to X'11'.</div></div>
<p><strong>Reference information:</strong> For more information
about the DFSMSdss patch byte, see </p>
<ul>
<li>INFO APAR II14616.</li>
<li>>z/OS DFSMSdss Storage Administration</a>.</li></ul>
<h3 id="hsmarccat">DFSMShsm: Stop using the HOLD command to quiesce activity prior
to control data set backup</h3>
<p><strong>Description:</strong> Before z/OS V1R13, you might have manually or programmatically
held DFSMShsm activity using the <strong>HOLD</strong> command
prior to starting a control data set (CDS) backup. Starting with z/OS V1R13, the ARCCAT resource
is released by all functions running on z/OS V1R13
DFSMShsm hosts, and the functions are quiesced when CDS backup starts.
Manually or programmatically holding DFSMShsm activity is no longer
necessary.<a id="idx711"></a><a id="idx712"></a></p>
<table id="wq427" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because DFSMShsm will automatically
release the ARCCAT resource when a CDS backup is starts.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>Cross coupling facility (XCF) services are required
to communicate the start of a CDS backup to all DFSMShsm hosts. XCF
services must be available and configured properly.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>The following are restrictions of taking this
migration action.
<ul>
<li>In a record-level sharing (RLS) CDS environment, all DFSMShsm
hosts in the HSMPlex must be z/OS V1R13
or later hosts.</li>
<li>In a non-RLS CDS environment, this migration action can be taken
on z/OS V1R13 DFSMShsm hosts
without changing hosts running on prior releases of z/OS.</li>
<li>Some DFSMShsm environment configuration do not require XCF services.
Specifically, a non-RLS CDS non-multiple address space DFSMShsm (MASH)
configuration typically does not require XCF services. However, XCF
services are required and must be available and configured in all
DFSMShsm RLS CDS and MASH configurations.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If you continue to issue a HOLD command to quiesce
DFSMShsm activity before a CDS backup and a corresponding RELEASE
command to resume activity after CDS backup is complete, the only
impact is that you will not see the performance benefit intended by
this enhancement.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> On all z/OS V1R13 DFSMShsm hosts:</p>
<ol type="1">
<li>Remove the procedures, processes, or programs that issue the <strong>HOLD</strong> command to quiesce DFSMShsm activity prior
to starting CDS backup.</li>
<li>Remove the corresponding procedures, processes, or programs that
issue the <strong>RELEASE</strong> command to resume DFSMShsm
activity after CDS backup completes.</li></ol>
<p><strong>Reference information:</strong> For an overview of
the CDS backup enhancement that relieves ARCCAT resource contention,
see ll >z/OS DFSMS Using the New Functions</a>.</p>
<h1 id="dfsomig">DFSORT migration
actions</h1>
<div>
<div class="head2"><a href="#wq429" class="ptoclink">DFSORT actions
to perform before installing z/OS V1R13</a></div>
<div class="head2"><a href="#wq430" class="ptoclink">DFSORT actions
to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a href="#dfsomsg" class="ptoclink">Update automation for changed DFSORT messages</a></div>
<div class="head2"><a href="#wq432" class="ptoclink">DFSORT actions
to perform after the first IPL of z/OS V1R13</a></div>
<div class="head3"><a href="#mowrk" class="ptoclink">Use new MOWRK option to prevent the use of memory object storage
for work space sort applications</a></div>
<div class="head3"><a href="#dynallo" class="ptoclink">Change the number of dynamically allocated work data sets using
new DYNAPCT option</a></div></div>
<p>This topic describes migration actions for optional feature DFSORT.</p><a id="idx713"></a>
<h2 id="wq429">DFSORT actions
to perform before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq430">DFSORT actions
to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes DFSORT migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx714"></a><a id="idx715"></a><a id="idx716"></a><a id="idx717"></a><a id="idx718"></a><a id="idx719"></a>
<h3 id="dfsomsg">Update automation for changed DFSORT messages</h3>
<p><strong>Description:</strong> In z/OS V1R12, the text for some DFSORT messages (ICE<var class="pv">xxxx</var>)
is changed. Text and insert fields have been added, changed, or removed
in the messages listed below in &quot;Steps to take&quot;. These changes
can affect automation programs that examine the text of the messages.</p>
<table id="wq431" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation routines that examine
the message text of the messages listed below in &quot;Steps to take&quot;.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update your automation to
handle the following DFSORT message
changes:</p>
<ul>
<li>The release level has changed from "V1R10" to "V1R12" in message
ICE000I.</li>
<li>The following new messages have been added:
<ul>
<li>ICE236I</li>
<li>ICE248I</li>
<li>ICE249I</li>
<li>ICE264I</li>
<li>ICE278I</li>
<li>ICE299I</li>
<li>ICE801I</li></ul></li>
<li>Text and insert fields have been changed in the following messages
to provide new information:
<ul>
<li>ICE199I</li>
<li>ICE255I</li>
<li>ICE289A</li>
<li>ICE897I</li>
<li>ICE898I</li></ul></li></ul>
<p><strong>Reference information:</strong> For details about
the ICE messages, see >z/OS DFSORT Messages, Codes and Diagnosis Guide</a>.</p>
<h2 id="wq432">DFSORT actions
to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes DFSORT migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx720"></a><a id="idx721"></a><a id="idx722"></a><a id="idx723"></a><a id="idx724"></a><a id="idx725"></a>
<h3 id="mowrk">Use new MOWRK option to prevent the use of memory object storage
for work space sort applications</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R12, DFSORT uses memory object storage as
intermediate work space. A new installation option, MOWRK, specifies
whether memory object storage can be used for intermediate work space
or as an extension of main storage, as appropriate, or only as an
extension of main storage. Using memory object storage as intermediate
work space is the preferred choice. DFSORT's shipped installation
default for MOWRK is YES (use memory object storage as work space
or as an extension of main storage). If appropriate, you can change
MOWRK for all DFSORT sort applications to only use memory objects
as an extension of main storage by specifying NO. <a id="idx726"></a><a id="idx727"></a><a id="idx728"></a></p>
<p>The MOSIZE installation default will still limit the total amount
of memory object storage that can be used by a sort application.</p>
<table id="wq433" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the default value YES is not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>To prevent the use of memory object storage for work space for
all DFSORT sort applications, use ICEPRM<var class="pv">xx</var> members activated
by a START ICEOPT started task command to set the MOWRK=NO option,
as appropriate.</li>
<li>Alternatively, you can set MOWRK=NO with the previous (less
preferred) method of using the ICEMAC macro and usermods.</li>
<li>To prevent the use of memory object storage for work space for
individual DFSORT sort applications, use the NOMOWRK run time option
as described in the referenced documentation below.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li> For details about the MOWRK installation option, see >z/OS DFSORT Installation and Customization</a>.</li>
<li>For details about the MOWRK and NOMOWRK run time options, see >z/OS DFSORT Application Programming Guide</a>.</li></ul>
<h3 id="dynallo">Change the number of dynamically allocated work data sets using
new DYNAPCT option</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R12, you will see an increase in the number
of dynamically allocated work data sets for sort applications. A new
installation option, DYNAPCT, specifies a percentage that is applied
to the DYNALOC/DYNALLOC value in effect to determine the number of
additional work data sets to be dynamically allocated. These additional
work data sets will be allocated with 0 space and only used if needed
to complete a sort when the disk work space requirement is unexpectedly
larger than anticipated. The total disk work space initially allocated
by DFSORT will not increase.</p>
<p>DFSORT's shipped installation default for DYNAPCT is 10 (percent).
If appropriate, you can adjust DYNAPCT for all DFSORT sort applications
or for individual DFSORT sort applications by specifying 0 to 254
(percent) or OLD (no change from previous releases). DYNAPCT=0
indicates a 0 percentage, so no additional work data sets will be
added.<a id="idx729"></a><a id="idx730"></a></p>
<div>
<div class="notetitle" id="wq434">Note:</div>
<div class="notebody">DYNAPCT=OLD tells DFSORT to operate the
way it did previously: 
<ul>
<li>OLD specifies that additional work data sets should only be allocated
when DFSORT cannot determine the file size. When DFSORT is able to
determine the file size, additional work data sets will not be allocated
(<var class="pv">y</var>=0), and the total number of work data sets will be <var class="pv">n</var>.</li></ul>
<p>DYNAPCT=0 tells DFSORT to use 0%, which means no additional
work data sets will be allocated.</p></div></div>
<table id="wq435" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the default of 10 (percent) is not acceptable. 
<div>
<div class="notetitle" id="wq436">Note:</div>
<div class="notebody">If DYNAPCT=10 is not sufficient to avoid out of space ABENDs,
then you might want to raise the value of <var class="pv">n</var>.</div></div></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>To change the number of dynamically allocated work data sets for
all DFSORT sort applications, use ICEPRM<var class="pv">xx</var> members activated
by a START ICEOPT started task command to set the  DYNAPCT=<var class="pv">x</var> or
DYNAPCT=OLD option, as appropriate.</li>
<li>Alternatively, you can set DYNAPCT=<var class="pv">x</var> or DYNAPCT=OLD with
the previous (less preferred) method of using the ICEMAC macro and
usermods.</li>
<li>To change the number of dynamically allocated work data sets for
individual DFSORT applications, use the DYNAPCT=<var class="pv">x</var> or DYNAPCT=OLD
run time option as described in the referenced documentation below.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about the DYNAPCT installation option, see >z/OS DFSORT Installation and Customization</a>.</li>
<li>For details about the DYNAPCT run time option, see >z/OS DFSORT Application Programming Guide</a>.</li></ul>
<h1 id="dfsmiga">Distributed File Service migration actions</h1>
<p>This topic describes migration actions for base element Distributed
File Service.</p><a id="idx731"></a>
<h2 id="wq437">Distributed File Service actions to perform before installing z/OS V1R13</h2>
<p>This topic describes Distributed File Service migration actions
that you can perform on your current (old) system. You do not need
the z/OS V1R13 level of code
to make these changes, and the changes do not require the z/OS V1R13 level of code to run
once they are made.</p><a id="idx732"></a><a id="idx733"></a><a id="idx734"></a><a id="idx735"></a>
<h3 id="newdasd">zFS: Accommodate new DASD space requirements</h3>
<p><strong>Description:</strong> zFS always reads and writes
data in 8K blocks. However, in z/OS V1R13,
zFS stores data either inline or in 8K blocks. (Inline data is a file
that is smaller than 53 bytes and is stored in the file's metadata.)
Unlike in previous releases, zFS R13 no longer stores data in 1K fragments.
zFS R13 can read data stored in fragments; however, when the data
is updated, it is moved into 8K blocks. Previously, zFS could store
data in 1K fragments (contained in an 8K block). This meant that multiple
small files could be stored in a single 8K block. <a id="idx736"></a><a id="idx737"></a></p>
<p>Because data is no longer stored in fragments, zFS R13 might need
more DASD storage than was required in previous releases to store
the same amount of data. More storage may also be needed if zFS R13
is in a mixed-release sysplex and becomes the zFS owning system of
a file system.</p>
<ul>
<li><strong>Scenario 1:</strong> If every file in the file system
is 1K or less, zFS R13 could require up to four times the DASD storage
as was needed in previous releases.</li>
<li><strong>Scenario 2:</strong> Because HFS uses 4K blocks to
store data and zFS uses 8K blocks, if every file in the file system
were 4K or less, zFS R13 could require up to twice as much DASD space
to store these files.</li>
<li><strong>Scenario 3:</strong> If the file system contains
1000 files that are 1K in size, zFS in R13 could take a maximum of
10 cylinders more than zFS in previous releases.</li></ul>
<p>Typically, however, any increase in the DASD storage used by zFS
R13 will be negligible. For example, the z/OS V1R13 version root file system copied using
zFS R13 takes approximately 2% more space than the same file system
copied using zFS R11. Note that zFS R13 packs multiple ACLs and symbolic
links into an 8K block which previous releases did not do. To minimize
the chance of application failure because of running out of DASD storage
in newly mounted file systems, the default value for the IOEFSPRM
option aggrgrow is changed from <span class="pk">Off</span> to <span class="pk">On</span>.</p>
<table id="wq438" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you will be using zFS V1R13 to create
new zFS file systems or update data in existing file systems, where
the file system contains many small files. 
<p>This action is also
required if you have not specified the zFS aggrgrow option in your
IOEFSPRM configuration options file.</p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>zFS R13 may use more DASD storage for data than
previous releases required. The amount of DASD storage depends on
file sizes and on ACL and symbolic link usage. In general, the more
small files in the file system, the more likely it is that a file
system created or updated with zFS R13 will require more DASD storage
than previous releases.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Perform the following steps,
as appropriate for your installation.</p>
<div>
<span class="pblktitle">For all zFS file systems</span>
<ol type="1">
<li>If you have not specified the zFS aggrgrow option in your IOEFSPRM
configuration options file, recognize that the default is changing
in z/OS V1R13 from aggrgrow=off
to aggrgrow=on. This means that by default, a zFS read-write mounted
file system that is mounted on z/OS V1R13
will attempt to dynamically extend when it runs out of space if a
secondary allocation size is specified and there is space on the volume(s).</li>
<li>If you do not want that default change and you want it to act
as in prior releases, specify aggrgrow=off in your IOEFSPRM configuration
options file so that it takes effect on the next IPL. You can dynamically
change the aggrgrow option to off with the <span class="pk">zfsadm config -aggrgrow
off</span> command. You can see your current value for aggrgow with
the <span class="pk">zfsadm configquery -aggrgrow</span> command.</li></ol></div>
<div>
<span class="pblktitle">For new zFS file systems</span>
<ol type="1">
<li>Increase the estimated size of a new zFS file system, if you know
that many files in the file system will be small.</li>
<li>Mount zFS read-write file systems and allow them to dynamically
extend; if more DASD space is needed, applications will not fail because
the file systems are out of storage. 
<p>To do so, mount the file systems
with the AGGRGROW mount option or use the default aggrgrow=on IOEFSPRM
configuration option. The data set must have a non-zero secondary
allocation size and there must be space on the volume to allow dynamic
extension.</p></li></ol></div>
<div>
<span class="pblktitle">For existing zFS file systems</span>
<ol type="1">
<li>Use the scan for small files utility (zfsspace) to determine if
an existing file system needs more DASD storage. For a mounted zFS
file system, the utility shows the number of small files (1K or less),
if a secondary allocation is specified, and if aggrgrow=on is specified.You
can determine how many files you have in a file system that are less
than or equal to 1K in size by using the following shell command:
<pre class="xmp"><code><span class="pk">find  &lt;mountpoint> -size -3 -type f -xdev | wc -l </span></code></pre>
<p>The
zfsspace utility can be downloaded from <a href="ftp://public.dhe.ibm.com/s390/zos/tools/zfsspace/zfsspace.txt">ftp://public.dhe.ibm.com/s390/zos/tools/zfsspace/zfsspace.txt</a>.<a id="idx738"></a></p></li>
<li>If a file system has a secondary allocation size and is mounted
with the AGGRGROW mount option, allow it to dynamically extend to
minimize the potential failure because of lack of storage. If there
are insufficient candidate volumes, also consider adding volumes by
using the IDCAMS ALTER command with the ADDVOLUMES option. Generally,
after adding volumes, a remount samemode is required to have them
take effect.</li>
<li>If a file system is not enabled to dynamically extend, consider
explicitly growing the file system using the z/OS UNIX <span class="pk">zfsadm
grow</span> command. This is especially important if the file system
contains many small files that will be updated.</li>
<li>If you expect a file system to grow larger than 4GB (about 5825
3390 cylinders) and it is not SMS-managed with extended addressability,
you will need to copy it to an SMS-managed zFS data set with
a data class that includes extended addressability. To do so, use
the <span class="pk">pax</span> command. If a zFS aggregate is to be larger than
4GB, it must be SMS-managed with a data class that includes
extended addressability.</li></ol></div>
<p><strong>Reference information:</strong> Refer to the following
documentation for more information about the migration steps.</p>
<ul>
<li>For information about zFS administration tasks and how zFS stores
files, see >z/OS Distributed File Service zSeries File System Administration</a>>z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For information about VSAM extended addressability and SMS-managed
data sets, see >z/OS DFSMS Implementing System-Managed Storage</a>.</li>
<li>For information about the <span class="pk">pax</span> command, see >z/OS UNIX System Services Command Reference</a>.</li></ul>
<h3 id="clonewith">zFS: Copy cloned file systems to a compatibility mode aggregate</h3>
<p><strong>Description:</strong> z/OS V1R13
is planned to be the last release that zFS will support cloning file
systems. In anticipation of this removal of support, you should discontinue
using zFS clone functions, such as the <strong>zfsadm clone</strong> and <strong>zfsadm clonesys</strong> commands. You should also discontinue
mounting any zFS file system aggregates that contain a cloned (.bak)
file system.<a id="idx739"></a><a id="idx740"></a></p>
<p>When support for cloning file systems is withdrawn, only zFS compatibility
mode aggregates will be supported.</p>
<table id="wq445" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(previewed in z/OS V1R13 Software
Announcement 211-007, dated 15 February 2011).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation uses cloned file systems.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ol type="1">
<li>Determine if cloned file systems (.bak) have been created or are
in the process of being created on your system. 
<ul>
<li>Issue the <strong>modify zfs,query</strong> command and review
the contents of the FILE report. The Flg field in the report will
indicate the status of the file system aggregate.</li></ul></li>
<li>If your system contains cloned file systems, copy that data to
a compatibility mode aggregate.</li></ol>
<p><strong>Reference information:</strong> For more information
about zFS commands and performing administration tasks, see >z/OS Distributed File Service zSeries File System Administration</a>>z/OS Distributed File Service zSeries File System Administration</a>.</p>
<h3 id="msaggreg">zFS: Copy data from zFS multi-file system aggregates to zFS
compatibility mode aggregates</h3>
<p><strong>Description:</strong> z/OS V1R13
is planned to be the last release of zFS support for multi-file
system aggregates. If you have data stored in zFS multi-file system
aggregates, you should copy the data from the zFS multi-file system
aggregates into zFS compatibility mode aggregates. <a id="idx741"></a><a id="idx742"></a></p>
<p>When this support is withdrawn, only zFS compatibility mode aggregates
will be supported.</p>
<table id="wq447" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(previewed in z/OS V1R13 Software
Announcement 211-007, dated February 15, 2011).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation uses multi-file
system aggregates.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check ZOSMIGV1R11_ZFS_RM_MULTIFS or check
ZOSMIGREC_ZFS_RM_MULTIFS to help determine if any multi-file system
aggregates are attached on your system.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use one of the following methods
to determine if you are using zFS multi-file system aggregates:</p>
<ul>
<li>Use the IBM Health Checker
for z/OS check referenced above.</li>
<li>Scan your zFS IOEFSPRM configuration options file for define_aggr
statements.</li>
<li>Scan your /etc/rc file for any <strong>zfsadm attach</strong> commands.</li>
<li>Issue the <strong>zfsadm aggrinfo</strong> command to determine
if an aggregate is a multi-file system aggregate; in the command response,
COMP indicates compatibility mode and MULT indicates multi-file system.</li></ul>
<p> If you are using zFS multi-file system aggregates, copy the data
from each of those file systems into its own zFS compatibility mode
aggregate.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about zFS commands and administration tasks,
see >z/OS Distributed File Service zSeries File System Administration</a>>z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For more information about IBM health
checks, refer to >IBM Health Checker for z/OS: User&rsquo;s Guide</a> >IBM Health Checker for z/OS: User&rsquo;s Guide</a>.</li></ul>
<h3 id="filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</h3>
<p><strong>Description:</strong> In z/OS V1R13, zFS only runs in sysplex=filesys mode.
This requires that all sysplex members in the shared file system environment
must run sysplex=filesys, including any z/OS V1R11
and z/OS V1R12 systems.<a id="idx743"></a><a id="idx744"></a><a id="idx745"></a></p>
<table id="wq448" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have a shared file system environment
with more than one system in that environment.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>Install the PTF for APAR OA32925 on z/OS V1R11.
<p>If a problem occurs
when zFS is running sysplex=filesys on a z/OS V1R11 or z/OS V1R12
system, you can perform the following steps:</p>
<ul>
<li>Remove the sysplex specification from each system or specify sysplex=off
on each system (this is equivalent to the default).</li>
<li>Perform a rolling IPL or restart zFS on each system.</li></ul>
<p>This procedure cannot be done after zFS on the z/OS V1R13 system has joined the
sysplex. If you try to start zFS on another z/OS V1R13 system after you have changed zFS to
sysplex=off on the z/OS V1R11
or z/OS V1R12 system, zFS on z/OS V1R13 will not start. This
happens because zFS on z/OS V1R13
requires all other systems be zFS sysplex=filesys.</p>
<p>Also, if
you try to bring in zFS z/OS V1R13
when sysplex=filesys is not active on all systems, you will receive
message <samp class="xph">IOEZ00721I Sysplex member <span class="mv">sysname</span> is not running
sysplex=filesys. zFS on this initializing member will terminate.</samp>,
where <span class="mv">sysname</span> is the sysplex member that is not running sysplex=filesys.</p></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Specifying zFS sysplex=filesys in a shared file
system environment causes zFS to run sysplex-aware on a file system
basis. This is the preferred mode for zFS in a shared file system
environment.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check ZOSMIGV1R13_ZFS_FILESYS<span>(available
with APAR OA35465 on z/OS V1R12
and z/OS V1R11)</span>.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Perform the following steps
to ensure that sysplex=filesys is available on all zFS z/OS V1R11 and z/OS V1R12 systems in a shared file system environment.</p>
<ol type="1">
<li>Install the PTF for APAR OA32925 (UA55765) on all z/OS V1R11 systems, and make it
active on all systems through a rolling IPL. This provides the enhanced
connect function required by zFS V1R13.</li>
<li>If you are currently running zFS sysplex=off, specify sysplex=filesys
and make it active on all systems through a rolling IPL. 
<p>If you
are running sysplex=on, specify sysplex=filesys and sysplex_filesys_sharemode=rwshare
and make it active on all systems through a rolling IPL. <span>The
health check ZOSMIGV1R13_ZFS_FILESYS verifies that all z/OS V1R11 and z/OS V1R12 systems in the shared file system environment
have specified sysplex=filesys before z/OS V1R13
is introduced.</span></p></li></ol>
<p>To determine if you are running zFS sysplex=filesys, issue the
MODIFY ZFS,QUERY,LEVEL operator command. In a shared file system environment,
the last line of the response indicates if zFS is running sysplex=filesys.
In the following example, zFS is running sysplex=filesys.  </p>
<pre class="xmp"><code>f zfs,query,level
IOEZ00639I zFS kernel: z/OS zSeries File System
Version 01.11.00 Service Level OA33895 - HZFS3B0.
Created on Mon Aug 23 14:02:18 EDT 2010.
sysplex(<strong>filesys</strong>,norwshare) interface(3)
IOEZ00025I zFS kernel: MODIFY command - QUERY,LEVEL completed successfully</code></pre>
<p>If you do not perform these steps on z/OS V1R11
or z/OS V1R12 systems, you
will receive error messages when you try to bring up zFS on a z/OS V1R13 system. In the examples
shown in <a href="#zfsemsg">Table 13</a>, DCEIMGVM, DCEIMGVN and DCEIMGVQ are
three sysplex members in a shared file system environment.</p>
<table id="zfsemsg" width="100%" summary="" border="1" frame="hsides" rules="rows">
<caption>Table 13. Examples of zFS error messages</caption>
<tbody valign="top">
<tr>
<td width="11%"><strong>Example 1</strong></td>
<td width="88%">DCEIMGVM (running z/OS V1R13)
tries to enter the sysplex environment. 
<p>DCEIMGVN and DCEIMGVQ are
running z/OS V1R11 but the
coexistance APAR has not been installed on either system.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVM (z/OS V1R13)
issues:
<pre class="xmp"><code>IOEZ00675E zFS will terminate... system DCEIMGVN does not support the following
           feature(s) used by this system (DCEIMGVM):
           enhanced connect
IOEZ00675E zFS will terminate... system DCEIMGVQ does not support the following
           feature(s) used by this system (DCEIMGVM):
           enhanced connect
IOEZ00057I zFS kernel program IOEFSKN is ending</code></pre></td>
</tr>
<tr>
<td><strong>Example 2</strong></td>
<td>DCEIMGVN (running z/OS V1R11
without coexistence APAR) tries to enter the sysplex environment.
<p>DCEIMGVM
and DCEIMGVQ are running z/OS V1R13.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVN (z/OS V1R11)
issues the following messages:
<pre class="xmp"><code>IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s) not supported
           by the initializing system (DCEIMGVN).
IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s) not supported
           by the initializing system (DCEIMGVN).
IOEZ00057I zFS kernel program IOEFSCM is ending</code></pre>
<p>DCEIMGVM (z/OS V1R13) issues:</p>
<pre class="xmp"><code>IOEZ00676E DCEIMGVN will terminate... it does not support the following
           feature(s) used by this system(DCEIMGVM):
           enhanced connect</code></pre>
<p>DCEIMGVQ (z/OS V1R13) issues:</p>
<pre class="xmp"><code>IOEZ00676E DCEIMGVN will terminate... it does not support the following
           feature(s) used by this system(DCEIMGVQ):
           enhanced connect</code></pre></td>
</tr>
<tr>
<td><strong>Example 3</strong></td>
<td>DCEIMGVM (running z/OS V1R13)
tries to enter the sysplex environment.
<p>DCEIMGVN and DCEIMGVQ
(running z/OS V1R11 with the
coexistance APAR installed) are not running sysplex=filesys.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVM (z/OS V1R13)
issues: 
<pre class="xmp"><code>IOEZ00721I Sysplex member DCEIMGVN is not running sysplex=filesys.
           zFS on this initializing member will terminate.
IOEZ00721I Sysplex member DCEIMGVQ is not running sysplex=filesys.
           zFS on this initializing member will terminate.
IOEZ00057I zFS kernel program IOEFSKN is ending.</code></pre></td>
</tr>
<tr>
<td><strong>Example 4</strong></td>
<td>DCEIMGVN (running z/OS V1R11
without sysplex=filesys and with the coexistence APAR installed) tries
to enter the sysplex environment. 
<p>DCEIMGVM and DCEIMGVQ are running z/OS V1R13.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVN (z/OS V1R11
without sysplex=filesys) issues:  
<pre class="xmp"><code>IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s)
           not supported by the initializing system (DCEIMGVN).
IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s)
           not supported by the initializing system (DCEIMGVN).
IOEZ00057I zFS kernel program IOEFSCM is ending</code></pre>DCEIMGVM (z/OS V1R13) issues:
<pre class="xmp"><code>IOEZ00720I Initializing system DCEIMGVN will not be allowed
           to join the sysplex.
           It is not running sysplex=filesys.</code></pre>DCEIMGVQ (z/OS V1R13) issues:  
<pre class="xmp"><code>IOEZ00720I Initializing system DCEIMGVN will not be allowed
           to join the sysplex.
           It is not running sysplex=filesys.</code></pre></td>
</tr>
</tbody>
</table>
<p><strong>Reference information:</strong> Refer to the following
documentation for more information about these migration steps.</p>
<ul>
<li>For details about messages, see >z/OS Distributed File Service Messages and Codes</a>.</li>
<li>For more information about running zFS in a shared file system
environment, see >z/OS Distributed File Service zSeries File System Administration</a>>z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For more information about IBM health
checks, refer to >IBM Health Checker for z/OS: User&rsquo;s Guide</a> >&amp;e0zl100t;</a>.</li></ul>
<h3 id="zfsvirtst">zFS: Verify virtual storage usage</h3><a id="idx746"></a>
<p><strong>Description:</strong> Applying PTF UA55765 (zFS APAR
OA33451) to z/OS V1R11 fixes
a performance problem that occurs because of too many storage obtains
and releases in zFS. The resolution of the problem involves obtaining
a new block of storage at zFS initialization. This storage obtain
is for approximately 60 MB.</p>
<table id="wq450" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11
by APAR OA33451.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without APAR OA33451.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If your zFS virtual storage usage is close to
the limit of the zFS address space, this additional virtual storage
request at zFS initialization could cause zFS to fail to initialize
and not come up, or zFS may come up but with insufficient remaining
storage to handle zFS requests such as mount. In these cases, you
would likely see zFS the warning message <strong>IOEZ00662I:
ZFS is low on storage</strong>.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Verify that PTF UA55765 (zFS APAR OA33451) is installed.</li>
<li>Check zFS storage usage by using the operator command <span class="pk">MODIFY
ZFS,QUERY,STORAGE</span>.  If you compare the third line of data (USS/External
Storage Access Limit) to the fourth line (Total Bytes Allocated (Stack+Heap+OS)),
you will be able to see how close zFS is to using its maximum storage.
 The Total Bytes Allocated should be less than the USS/External Storage
Access Limit.  For example:
<pre class="xmp"><code>MODIFY ZFS,QUERY,STORAGE
IOEZ00438I Starting Query Command STORAGE.
                 zFS Primary Address Space Storage Usage
                 ---------------------------------------

Total Storage Available to zFS: 1938817024 (1893376K) (1849M)
Non-critical Storage Limit: 1917845504 (1872896K) (1829M)
USS/External Storage Access Limit: 1875902464 (1831936K) (1789M)
Total Bytes Allocated (Stack+Heap+OS): 245559296 (239804K) (234M)
Heap Bytes Allocated: 213411011 (208409K) (203M)
Heap Pieces Allocated: 295003
Heap Allocation Requests: 295610
Heap Free Requests: 607

             Heap Usage By Component
            --------------------------
Bytes               No. of  No. of
Allocated   Pieces  Allocs  Frees   Component
----------  ------  ------  ------  ---------
     66836      10      10       0  Interface
      5112       8      12       4  Media Manager I/O driver
      1828       5       5       0  Trace Facility
    431452       7       7       0  Message Service
    282789    1701    2216     515  Miscellaneous
     34632      41      43       2  Aggregate Management
    106220      31      31       0  Filesystem Management
     33128      23      29       6  Administration Command Handling
  35115496  100692  100692       0  Vnode Management
  17030164   36313   36315       2  Anode Management
  34838428    7140    7146       6  Directory Management
    475992    6170    6172       2  Log File Management
  34459280   12299   12300       1  Metadata Cache
    420312    4014    4014       0  Transaction Management
      9740      24      24       0  Asynchronous I/O Component
     58288     156     156       0  Lock Facility
    169224     443     443       0  Threading Services
    249200    5968    5972       4  Cache Services
     46058       6       8       2  Configuration parameters processing
  11842136   98386   98386       0  User File Cache
     56100      99     118      19  Storage Management
  63318828     942     950       8  XCF Services
     11640       8      10       2  Cross system attach validation
   2338560   20489   20489       0  Server Token Manager (STKM)
     12048      16      16       0  Server Token Cache (STKC)
  11996704       8       8       0  Client Token Cache (CTKC)
         0       0       0       0  Server Vnode Interface (SVI)
       816       4      38      34  Name Space (NS)</code></pre>You can see
that, in this case, the Total Bytes Allocated (234M) is much less
than the USS/External Storage Access Limit (1789M).  If the Total
Bytes Allocated becomes greater than or equal to the USS/External
Storage Access Limit, zFS will issue an IOEZ00662I message. 
<p>If
you see that the Total Bytes Allocated approaches the value of the
USS/External Storage Access Limit, you should take steps to decrease
your cache sizes using the z/OS UNIX zfsadm config command.  See
the z/OS Distributed File Service zSeries File System Administration
(SC24-5989) for more information on the zfsadm command.</p></li>
<li>If zFS has failed to initialize and is not active, you should
decrease some of your zFS IOEFSPRM settings, such as dir_cache_size,
meta_cache_size, recovery_max_storage, token_cache_size, tran_cache_size,
vnode_cache_size (especially if they are significantly larger than
the default for these values) and restart zFS. If zFS is active but
warning message IOEZ00662I has been issued, you can attempt to decrease
the caches dynamically using the zfsadm config command. (You should
also make the corresponding changes in your IOEFSPRM file for the
next zFS restart.) Alternatively, you can stop and restart zFS after
making cache size changes to your IOEFSPRM file.
<p></p></li></ol><p class="indatacontent">As a general practice, it is a good idea to periodically check
zFS storage usage by using the operator command <span class="pk">MODIFY ZFS,QUERY,STORAGE</span>.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about the zfsadm command, see >z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For more information about zFS administration, see >z/OS Distributed File Service zSeries File System Administration</a>.</li></ul>
<h2 id="wq452">Distributed File Service actions to perform before the first
IPL of z/OS V1R13</h2>
<p>This topic describes Distributed File Service
migration actions that you can perform after you have installed z/OS V1R13 but before the first
time you IPL. These actions might require the z/OS V1R13 level of code to be installed but do
not require it to be active.</p><a id="idx747"></a><a id="idx748"></a><a id="idx749"></a><a id="idx750"></a><a id="idx751"></a><a id="idx752"></a>
<h3 id="disdfsc">DCE/DFS: Disable DFS Client initialization</h3>
<p><strong>Description:</strong> The DFS client (DFSCM) is a
physical file system that is started during z/OS UNIX initialization
based on a FILESYSTYPE statement in the BPXPRMxx parmlib member. Starting
with z/OS V1R13, the DFS client
function is removed.<a id="idx753"></a><a id="idx754"></a></p>
<table id="wq453" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(previewed in z/OS V1R12 Software
Announcement 210-235, dated July 22, 2010).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use ZOSMIGREC_SMB_RPC available by APAR OA30117.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> For parmlib updates, the following
members should be the only IOEx programs listed in the AUTHPGM section
of the IKJTSOxx parmlib member:</p>
<ul>
<li>IOEDFSXP</li>
<li>IOEAGSLV</li>
<li>IOEAGFMT</li>
<li>IOEZADM</li></ul><p class="indatacontent">All other IOEx programs need to be removed. You require TSO/E
APAR OA37218 for z/OS V1R13
to update samplib member IKJTSO00 to add a new entry for IOEDFSXP
to the AUTHPGM list.</p>
<p>If your installation uses the DFS client, you must remove the following
statement from the BPXPRM<var class="pv">xx</var> parmlib member to prevent the
client from initializing:</p>
<pre class="xmp"><code>FILESYSTYPE TYPE(DFSC)
	ENTRYPOINT(IOECMINI)
	PARM('ENVAR("_EUV_HOME=/opt/dfslocal/home/dfscm") /
	>DD:IOEDFSD 2>&amp;1')
	ASNAME(DFSCM)</code></pre>
<p>If this migration action is not performed before the first IPL
of z/OS V1R13, you will receive
the following error message: </p>
<pre class="xmp"><code>IOEP12402E:
As of z/OS Version 1 Release 13, the DFS client function has been removed.</code></pre><p class="indatacontent">z/OS UNIX will successfully initialize,
but you will need to follow the guidance in the message to remove
the entry and restart z/OS UNIX.</p>
<p>If you have not already done so, you should use the z/OS UNIX <strong>pax</strong> command to migrate any data in DCE DFS or Episode
file systems to other file systems. The recommended general procedure
is as follows:</p>
<ol type="1">
<li>Set up a zFS file system to receive the data.</li>
<li>Copy your DCE DFS or Episode file system data to the zFS file
system, using the z/OS UNIX <strong>pax</strong> command.</li>
<li>Set up a z/OS NFS server
to allow data access from a remote z/OS UNIX system.</li></ol>
<p><strong>Reference information:</strong> Refer to the following
documentation for more information about these migration steps.</p>
<ul>
<li>For details about message IOEP12402E, see  >z/OS Distributed File Service Messages and Codes</a>.</li>
<li>For information about setting up a zFS file system, see  >z/OS Distributed File Service zSeries File System Administration</a>>z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For information about the <strong>pax</strong> command, see
 >z/OS UNIX System Services Command Reference</a>>z/OS UNIX System Services Command Reference</a>.</li>
<li>For information about NFS, see  >z/OS Network File System Guide and Reference</a>.</li>
<li>For information about SMB, see >z/OS Distributed File Service SMB Administration</a> >&amp;ioea600t;</a>.</li></ul>
<h2 id="wq455">Distributed File Service actions to perform after the first
IPL of z/OS V1R13</h2>
<p>This topic describes Distributed File Service migration actions
that you can perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these actions.</p><a id="idx755"></a><a id="idx756"></a><a id="idx757"></a><a id="idx758"></a><a id="idx759"></a><a id="idx760"></a>
<p>None</p>
<h1 id="ai1info">Infoprint Server migration actions</h1>
<p>This topic describes migration actions for optional feature Infoprint
Server.</p><a id="idx761"></a>
<h2 id="wq456">Infoprint Server actions to perform before installing z/OS V1R13</h2>
<p>This topic describes Infoprint Server migration actions that you
can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are made.</p><a id="idx762"></a><a id="idx763"></a><a id="idx764"></a><a id="idx765"></a>
<h3 id="pispace">Increase space in the Printer Inventory file system</h3>
<p><strong>Description:</strong> In z/OS V1R12, the format of the Infoprint Server Printer Inventory
files has changed from Version 1 to Version 2 format. <span>When
you migrate from z/OS V1R11
and start Infoprint Server
on z/OS V1R13 for the first
time</span>, Infoprint Server
reformats the Version 1 Printer Inventory files and creates Version
2 Printer Inventory files. The Version 1 Printer Inventory files are
not removed so that if you need to fall back to z/OS V1R11, Infoprint Server can use the Version 1 Printer
Inventory files. Therefore, the Printer Inventory file system requires
more space in z/OS <span>V1R13
than in z/OS V1R11.</span> You
might need to increase space in the Infoprint Server Printer Inventory
file system. <a id="idx766"></a></p>
<table id="wq457" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>On z/OS V1R11
systems, Infoprint Server
cannot read or export the Version 2 Printer Inventory. If you want
to use the Version 2 Printer Inventory on z/OS V1R11, use the <strong>pidu</strong> command
to export the Version 2 Printer Inventory while running on z/OS V1R13 and then use the <strong>pidu</strong> command to import the exported copy to z/OS V1R11.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health
Checker for z/OS check:</strong></td>
<td>ZOSMIGV1R12_INFOPRINT_INVSIZE available
with APAR OA32093.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Do one of these: 
<ul>
<li>Run the IBM Health Checker
for z/OS check ZOSMIGV1R12_INFOPRINT_INVSIZE.</li>
<li>Run the <strong>df</strong> command to display the current
utilization of the Printer Inventory file system. Printer Inventory
files are located in the Infoprint Server base directory. The default
base directory name is /var/Printsrv.
<p>You might have changed the
base directory name in the <strong>base-directory</strong> attribute
in the aopd.conf configuration file. The aopd.conf default location
is /etc/Printsrv/aopd.conf. However, you might have specified a different
location in environment variable AOPCONF.</p>
<p>The free space required
is 200% of the sum of the Version 1 Printer Inventory and historical
Printer Inventory files (master.db, jestoken.db, pwjestoken.db, hinv/hinv.db,
and logdb/log.db).</p>
<p>If the &quot;Capacity&quot; is greater than 33%,
increase the size of the file system.</p>
<p><strong>Example:</strong></p>
<pre class="xmp"><code>df -P /var/Printsrv</code></pre>
<pre class="xmp"><code>Filesystem     512-blocks  Used   Available  Capacity  Mounted on
OE17A.S1.VAR   64800       54184  10616      84%       /DEVE/var</code></pre></li></ul></li>
<li>To increase the size of the file system, you can use the z/OS UNIX <strong>zfsadm grow</strong> (zFS) or <strong>confighfs</strong> (HFS)
command.</li></ol>
<p><strong>Tip:</strong> Set the <strong>aggrfull</strong> (zFS)
 or FSFULL (HFS) file system option so that warning messages are issued
if the Infoprint Server
base directory (/var/Printsrv) is getting full.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For information about the /var/Printsrv directory and how to use
the <strong>pidu</strong> command to export and import the Printer
Inventory, see >z/OS Infoprint Server Customization</a>.</li>
<li>For information about how to start and stop Infoprint Server, see >z/OS Infoprint Server Operation and Administration</a>.</li>
<li>For information about managing file systems, see >z/OS UNIX System Services Planning</a>.</li>
<li>For information about the <strong>zfsadm grow</strong> command
and the <strong>aggrfull</strong> option, see >z/OS Distributed File Service zSeries File System Administration</a></li>
<li>For information about the <strong>confighfs</strong> command,
see >z/OS UNIX System Services Command Reference</a>.</li></ul>
<h3 id="remv2pi">Remove Version 2 Printer Inventory files at fallback to z/OS V1R11</h3>
<p><strong>Description:</strong> In z/OS V1R12, the format of the Infoprint Server Printer
Inventory files has changed from Version 1 to Version 2 format. <span>When you migrate from z/OS V1R11
and start Infoprint Server on z/OS V1R13
for the first time</span>, Infoprint Server reformats the Version 1 Printer
Inventory files and creates Version 2 Printer Inventory files. Both
Version 1 and Version 2 Printer Inventory files exist in the Infoprint Server
base directory. Infoprint Server
on z/OS V1R13 uses the Version
2 Printer Inventory files. If you fall back to z/OS V1R11, Infoprint Server uses the Version 1 Printer
Inventory files.</p>
<p>If you start Infoprint Server
on z/OS <span>V1R13
a second time after falling back to z/OS V1R11,</span> Infoprint Server
uses the existing Version 2 Printer Inventory files that it created
the first time you started Infoprint Server on z/OS V1R13. It does not reformat the Version 1 Printer
Inventory files again.</p>
<p>If you want Infoprint Server
to reformat the Version 1 Printer Inventory files again, remove the
Version 2 Printer Inventory files before you start Infoprint Server
on z/OS V1R13. Because the
Version 2 Printer Inventory files no longer exist, Infoprint Server
reformats the Version 1 Printer Inventory files and creates a new
set of Version 2 Printer Inventory files.</p>
<p>In most cases, you should remove the Version 2 Printer Inventory
files if they exist. If you do not remove the Version 2 Printer Inventory
files, any changes that the administrator made to the Version 1 Printer
Inventory on z/OS V1R11 are
not in the Version 2 Printer Inventory. <a id="idx767"></a></p>
<table id="wq459" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you want Infoprint Server
to reformat the Version 1 Printer Inventory files after a fallback.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health
Checker for z/OS check:</strong></td>
<td>INFOPRINT_V2DB_CHECK available
with APAR OA32093.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Run the IBM Health Checker
for z/OS check INFOPRINT_V2DB_CHECK.</li>
<li>If Version 2 Printer Inventory files exist after falling back
to z/OS V1R11, remove them
from the Infoprint Server
base directory. Be careful not to remove any Version 2 files while
running z/OS V1R13 because Infoprint Server
on z/OS V1R13 requires Version
2 Printer Inventory files. 
<p>Version 2 files have the extension &quot;v2db&quot;.
The default base directory is /var/Printsrv.</p>
<p>You might have
changed the base directory name in the <strong>base-directory</strong> attribute
in the aopd.conf configuration file. The aopd.conf default location
is /etc/Printsrv/aopd.conf. However, you might have specified a different
location in environment variable AOPCONF.</p>
<p><strong>Example: </strong> These z/OS UNIX commands
switch to an effective UID of 0, remove all files with the &quot;v2db&quot; extension
from directory /var/Printsrv, and switch back to the original UID: </p>
<pre class="xmp"><code> su
 rm -f $(find /var/Printsrv/ -name "*.v2db")
 exit</code></pre>
<div>
<div class="notetitle" id="wq461">Note:</div>
<div class="notebody">To remove Printer Inventory files,
you must have an effective UID of 0 or be a member of the RACF AOPADMIN group.</div></div></li></ol>
<p><strong>Reference information:</strong> For information about
the /var/Printsrv directory, see >z/OS Infoprint Server Customization</a>.</p>
<h3 id="javaipp">Upgrade Java support
for IPP Server</h3>
<p><strong>Description:</strong> In z/OS V1R12, the Internet Printing Protocol (IPP)
Server component of Infoprint Server requires Java V6.0. If the JAVA_HOME environment variable
specifies the location of an earlier version of Java, you must update the JAVA_HOME environment variable. <a id="idx768"></a></p>
<table id="wq462" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13,
if APAR OA28720 is applied. Otherwise, after installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use IPP Server and specify the JAVA_HOME
environment variable. You are using IPP Server if the <strong>start-daemons={ippd}</strong> attribute
is specified in the Infoprint Server configuration file. The configuration
file's default location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However,
you might have specified a different location in environment variable
AOPCONF.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>IBM 31-bit
SDK for z/OS, Java Technology Edition, V6 (5655-R31)</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health
Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Install IBM 31-bit SDK for z/OS, Java 2
Technology Edition, V6 (5655-R31).</li>
<li>If you use the IPP Server, edit the <strong>aopstart</strong> EXEC
to update the directory path specified in the JAVA_HOME environment
variable. IPP Server requires the 31-bit version of Java V6.0.</li>
<li>If you use the z/OS HTTP
Server, update the setting of JAVA_HOME in the z/OS HTTP Server environment variables file <samp class="xph">httpd.envvars</samp>.</li></ol>
<div>
<div class="notetitle" id="wq464">Note:</div>
<div class="notebody">If you installed Java V6.0
in the default Java directories,
you do not need to specify the JAVA_HOME environment variable. If
JAVA_HOME is not specified, IPP Server looks for Java files in the <samp class="xph">/usr/lpp/java/J6.0</samp> 
directory.</div></div>
<p><strong>Reference information:</strong> For information about
how to edit the <strong>aopstart</strong> EXEC and the z/OS HTTP Server environment variables
file, see >z/OS Infoprint Server Customization</a>.</p>
<h2 id="wq465">Infoprint Server actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes Infoprint Server migration actions that you
can perform after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx769"></a><a id="idx770"></a><a id="idx771"></a><a id="idx772"></a><a id="idx773"></a><a id="idx774"></a>
<h3 id="ai3svco">Remount the Printer Inventory and copy files that were customized</h3>
<p><strong>Description:</strong> When migrating to z/OS V1R13 Infoprint Server, you
must bring forward the customized data from your previous system. <a id="idx775"></a><a id="idx776"></a><a id="idx777"></a></p>
<table id="wq466" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li><em>Printer Inventory:</em>
<ul>
<li>Remount the <samp class="xph">/var/Printsrv</samp> directory from the z/OS V1R11 or V1R12 system on the z/OS V1R13 system. The <samp class="xph">/var/Printsrv</samp> directory
contains the Printer Inventory as well as other Infoprint Server files.
The default directory is <samp class="xph">/var/Printsrv</samp>. However, you might
have changed the directory name in the base-directory attribute in
the <samp class="xph">aopd.conf</samp> configuration file.
<div>
<div class="notelisttitle" id="wq467">Notes:</div>
<ol type="1">
<li>After you start Infoprint Server on the z/OS system, you should use the Infoprint Server <strong>pidu</strong> command to export the Printer Inventory on
the z/OS V1R13 system so that
you have a backup of the Printer Inventory.</li>
<li>If <samp class="xph">/var/Printsrv</samp> is not mounted at a separate mount
point, use the Infoprint Server <strong>pidu</strong> command
to export the Printer Inventory on the original system and restore
it on the z/OS V1R13 system.
Do not use other copy commands to copy the Printer Inventory. (Mounting
/var/Printsrv at a separate mount point can result in better management
of disk space and easier migration.)</li>
</ol></div></li>
<li>Configure the Infoprint Server environment variables (for example,
AOPCONF, PATH, LIBPATH, NLSPATH, MANPATH) in <samp class="xph">/etc/profile</samp>.</li></ul></li>
<li><em>Configuration file:</em> If you modified the
Infoprint Server configuration file, copy the file to the z/OS V1R13 system. Its default
location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However, you might
have specified a different location in environment variable AOPCONF.</li>
<li><span class="bold-italic">aopstart</span> <em>EXEC:</em> If
you modified the <strong>aopstart</strong> EXEC, copy it
to the z/OS V1R13 system.</li>
<li><em>IP PrintWay&trade;:</em> If
you currently use the IP PrintWay component
of Infoprint Server, copy to the z/OS V1R13
system any IP PrintWay exit
routines and data stream filters you have written. <span>It
is a good practice to recompile the exits and filters on z/OS V1R13.</span></li>
<li><em>NetSpool:</em> If you currently use the NetSpool component
of Infoprint Server, copy to the z/OS V1R13
system any NetSpool exit
routines you have written. <span>It is a good practice to recompile
the exits and filters on z/OS V1R13.</span></li>
<li><em>Print Interface:</em> If you currently use
the Print Interface component of Infoprint Server, take these actions:
<ul>
<li>If you have written any data stream filters, copy them to the z/OS V1R13 system. You do not need
to recompile them.</li>
<li>If you run the SAP R/3 application server on the z/OS system, copy the SAP callback daemon configuration
file to the z/OS V1R13 system.
Its default location is <samp class="xph">/etc/Printsrv/aopsapd.conf</samp>. However,
you might have specified a different location in environment variable
AOPSAPD_CONF.</li></ul></li>
<li><em>Infoprint Central:</em> If you currently use
Infoprint Central, copy the z/OS HTTP
Server configuration and environment variables files to the z/OS V1R13 system. The default
locations of these files are <samp class="xph">/etc/httpd.conf</samp> and <samp class="xph">/etc/httpd.envvars</samp>.</li></ul>
<p><strong>Reference information:</strong> >z/OS Infoprint Server Customization</a>.</p>
<h3 id="regsizeao">Update or remove the region size in the AOPSTART startup procedure</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, the Infoprint Server startup procedure
AOPSTART specifies a region size of 512 megabytes. Before z/OS V1R13, AOPSTART did not specify
a region size, so the default region size defined for your installation
was used.</p>
<p>Because the default region size might not be sufficient to use
all the functions that Infoprint Server provides, it is a good practice
to specify a region size on the startup procedure. However, if you
want to continue to use the default region size or a region size other
than 512 megabytes, edit the AOPSTART procedure to remove the region
specification. If you have customized the AOPSTART procedure, you
can continue to use the customized version.<a id="idx778"></a><a id="idx779"></a></p>
<table id="wq469" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the AOPSTART procedure that IBM provides and want to continue
to use the default region size used in releases prior to z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health
Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Modify the EXEC statement in the AOPSTART procedure to remove
or alter the REGION parameter:
<pre class="xmp"><code>//AOPSTART EXEC PGM=AOPBATCH,PARM='//usr/lpp/Printsrv/bin/aopstart',
//             REGION=512M,
//             TIME=NOLIMIT</code></pre></li>
<li>Save the AOPSTART procedure.</li></ol>
<p><strong>Tips:</strong></p>
<ul>
<li>The AOPSTART procedure is distributed in SYS1.IBM.PROCLIB. However,
during installation it might have been copied to another data set
in the started task PROCLIB concatenation.</li>
<li>Specify a region size of at least 256 MB if you start the Infoprint
Server Transform Manager to run data stream transforms. (This
tip also applies to releases before z/OS V1R13.)</li>
<li>Specify a region size of at least 200 MB if you start the Infoprint
Server IPP Server to receive print requests from IPP-enabled
clients. (This tip also applies to releases before z/OS V1R13.)</li>
<li>User exits, such as IEFUSI, can modify the region size of an address
space. Do not alter the region size of address spaces in the OMVS
subsystem category.<a id="idx780"></a><a id="idx781"></a></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For information about the AOPSTART procedure, see >z/OS Infoprint Server Customization</a>.</li>
<li>For more information about the IEFUSI exit, see >z/OS MVS Installation Exits</a>.</li></ul>
<h3 id="isxml">Upgrade XML for Infoprint Central</h3>
<p><strong>Description:</strong> In z/OS V1R12, the Infoprint Central component of Infoprint
Server, which you can use to work with IP PrintWay extended mode print jobs and printers, requires
the IBM XML Toolkit for z/OS V1.10 (5655-J51) product. <a id="idx782"></a></p>
<table id="wq471" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Infoprint Central. You are using
Infoprint Central if the <strong>start-daemons={ssid}</strong> attribute
is specified in the Infoprint Server configuration file. The file's
default location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However, you
might have specified a different location in environment variable
AOPCONF.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td> IBM XML
Toolkit for z/OS V1.10 (5655-J51).</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Install IBM XML Toolkit
for z/OS V1.10 (5655-J51).</li>
<li>Specify the XML Toolkit for z/OS V1.10
libraries in the LIBPATH environment variable in your z/OS IBM HTTP
Server environment variables file (default location is <samp class="xph">/etc/httpd.envvars</samp>).
After z/OS V1R13 is installed,
Infoprint Central requires the XML Toolkit for z/OS V1.10 libraries: 
<ul>
<li>LIBPATH: change <samp class="xph">/usr/lpp/ixm/IBM/xml4c-5_6/lib</samp> to <samp class="xph">/usr/lpp/ixm/IBM/xml4c-5_7/lib</samp></li>
<li>LIBPATH: change <samp class="xph">/usr/lpp/ixm/IBM/xslt4c-1_10/lib</samp> to <samp class="xph">/usr/lpp/ixm/IBM/xslt4c-1_11/lib</samp></li>
<li>ICU_DATA: You can remove this variable because XML no longer uses
this variable.</li></ul></li>
<li>Restart the z/OS IBM HTTP Server to pick up the changes
to the environment variables file.</li></ol>
<p><strong>Reference information:</strong> For information about
how to customize Infoprint Central, see >z/OS Infoprint Server Customization</a>.</p>
<h3 id="btemode">Migrate from IP PrintWay basic
mode to extended mode</h3><a id="idx783"></a><a id="idx784"></a><a id="idx785"></a>
<p><strong>Description:</strong> Since z/OS V1R5, the IP PrintWay component
of Infoprint Server can operate in a mode called <em>IP PrintWay extended mode</em>.
IP PrintWay extended mode
uses the SYSOUT Application Programming Interface (SAPI) to obtain
output data sets from the JES spool. IP PrintWay extended mode provides better performance,
improved usability, and additional functions. For information about
the enhancements and limitations in extended mode, see >z/OS Infoprint Server Customization</a>.</p>
<p><em>IP PrintWay basic
mode</em> is the name used for the original IP PrintWay mode of operation. You can continue to run
IP PrintWay basic mode in z/OS V1R13. In future releases, IBM will make enhancements only
to IP PrintWay extended
mode.</p>
<p>You can run IP PrintWay basic
mode and IP PrintWay extended
mode at the same time only if you make sure that IP PrintWay basic mode and IP PrintWay extended mode select
different print jobs from the JES spool to print. Otherwise, unpredictable
results can occur.</p>
<table id="wq473" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>Basic mode was stabilized in z/OS V1R5. Extended mode was introduced in z/OS V1R5.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because it will become a
requirement in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>
<ul>
<li>If you use Infoprint Central to work with IP PrintWay extended mode print jobs and printers, you
need: 
<ul>
<li>An operating IBM HTTP Server
base element of z/OS</li>
<li>The XML Toolkit for z/OS V1.10
(5655-J51)</li>
<li>IBM 31-bit SDK for z/OS, Java Technology
Edition, V6 (5655-R31).</li>
<li>Microsoft Internet
Explorer 5.5, Netscape Navigator 7.0, or IBM Home
Page Reader 4.0 or later</li></ul></li>
<li>In addition to IBM 31-bit
SDK for z/OS, Java Technology Edition, V6 (5655-R31), one of the
following will also work:
<ul>
<li>IBM 64-bit SDK for z/OS, Java Technology
Edition, V6 (5655-R32)</li>
<li>IBM 31-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N98)</li>
<li>IBM 64-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N99)</li></ul></li>
<li>To use IP PrintWay extended
mode to print to VTAM-controlled printers, Infoprint Coaxial Printer
Support for z/OS (5655-N62)
is required.</li></ul></td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check INFOPRINT_PRINTWAY_MODE, available
with APAR OA26583, to determine if you are currently using IP PrintWay basic mode.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> See <a href="../com.ibm.zos.r13.aops000/pwemigration.htm">Migrating
from IP PrintWay basic mode
to extended mode</a> in >z/OS Infoprint Server Customization</a>.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS Infoprint Server Customization</a> describes
the features and limitations of IP PrintWay extended
mode and how to customize IP PrintWay extended
mode. It also describes how to customize the common message log and
Infoprint Central.</li>
<li>>z/OS Infoprint Server Operation and Administration</a> describes
how to log in to Infoprint Central and how to view messages in the
common message log. It also describes how to modify printer definitions
for IP PrintWay extended
mode.</li>
<li>>z/OS Infoprint Server User&rsquo;s Guide</a> describes
considerations for submitting print jobs when you use IP PrintWay extended mode.</li>
<li>>z/OS Infoprint Server Messages and Diagnosis</a> describes
how to trace IP PrintWay extended
mode.</li>
<li>The Infoprint Central online help system describes how to use
Infoprint Central.</li></ul>
<h2 id="wq474">Infoprint Server actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes Infoprint Server migration actions that you
can perform only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx786"></a><a id="idx787"></a><a id="idx788"></a><a id="idx789"></a><a id="idx790"></a><a id="idx791"></a>
<h3 id="runaops">Run aopsetup</h3><a id="idx792"></a>
<p><strong>Description:</strong> When migrating to z/OS V1R13 Infoprint Server, you
must run the <strong>aopsetup</strong> shell script to establish
the correct file permissions for Infoprint Server directories and
files.</p>
<table id="wq475" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Run the <strong>aopsetup</strong> shell
script from an rlogin shell, from an OMVS session, or with the BPXBATCH
command. Specify the names of the RACF groups
that you defined for Infoprint Server operators and administrators
as arguments to <strong>aopsetup</strong>. For example, if you
defined group AOPOPER for operators and group AOPADMIN for administrators,
enter:  </p>
<pre class="xmp"><code>/usr/lpp/Printsrv/bin/aopsetup AOPOPER AOPADMIN</code></pre>
<p><strong>Rule:</strong> You must run <strong>aopsetup</strong> from
a user ID with a UID of 0. You can use the <strong>su</strong> command
to switch to an effective UID of 0 if you have READ access to the
BPX.SUPERUSER profile in the RACF FACILITY
class.</p>
<p><strong>Tip:</strong> You can run <strong>aopsetup</strong> from
the driving system (instead of the target system) if all of these
are true:</p>
<ul>
<li>You have the target system's <samp class="xph">/var/Printsrv</samp> directory
accessible.</li>
<li>You reference the target system's <samp class="xph">/usr/lpp/Printsrv</samp> directory
mounted under a <samp class="xph">/service</samp> directory as described in the
comments at the beginning of the <strong>aopsetup</strong> shell
script.</li>
<li>The RACF database groups
for operators and administrators are the same on the driving and target
system.</li></ul>
<p><strong>Reference information:</strong> For details about <a href="../com.ibm.zos.r13.aops000/account.htm">running <strong>aopsetup</strong></a>,
see >z/OS Infoprint Server Customization</a>.</p>
<h3 id="remv1pi">Remove Version 1 Printer Inventory files after deploying z/OS V1R13</h3>
<p><strong>Description:</strong> <span>When you migrate
from z/OS V1R11 and start Infoprint
Server in z/OS V1R13 for the
first time</span>, Infoprint Server
reformats the Version 1 Printer Inventory files and creates Version
2 Printer Inventory files. <span>The Version 1 Printer Inventory
files are not removed so that if you need to fall back to z/OS V1R11, Infoprint Server can
use the Version 1 Printer Inventory files.</span><a id="idx793"></a></p>
<p>After you have fully deployed z/OS V1R13
and are sure that you will not need to fall back to z/OS V1R11, you can remove the Version 1 Printer
Inventory files to free up space in the Infoprint Server base directory.</p>
<table id="wq476" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to free up space in the Infoprint Server
base directory.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>If you need to fall back to z/OS V1R11 after removing the Version 1 Printer
Inventory files, use the <strong>pidu</strong> command to export
the Version 2 Printer Inventory on the z/OS V1R13
system and import the exported copy to the z/OS V1R11 system.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health
Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> </p>
<ol type="1">
<li>Remove the Printer Inventory Version 1 database files in the Infoprint Server
base directory. Version 1 files have a &quot;db&quot; extension. The default
base directory is /var/Printsrv. 
<p>You might have changed the base
directory name in the <strong>base-directory</strong> attribute
in the aopd.conf configuration file. The aopd.conf default location
is /etc/Printsrv/aopd.conf. However, you might have specified a different
location in environment variable AOPCONF.</p>
<p><strong>Example: </strong> These z/OS UNIX commands
switch to an effective UID of 0, remove all files with the &quot;db&quot; extension
from directory /var/Printsrv, and switch back to the original UID: </p>
<pre class="xmp"><code> su
 rm -f $(find /var/Printsrv/ -name "*.db")
 exit</code></pre> 
<div>
<div class="notetitle" id="wq478">Note:</div>
<div class="notebody">To remove Printer Inventory files,
you must have an effective UID of 0 or be a member of the RACF AOPADMIN group.</div></div></li></ol>
<p><strong>Reference information:</strong> For information about
the /var/Printsrv directory and how to use the <strong>pidu</strong> command
to export and import the Printer Inventory, see >z/OS Infoprint Server Customization</a>.</p>
<h1 id="aj1ispf">ISPF migration actions</h1>
<p>This topic describes migration actions for base element ISPF.</p><a id="idx794"></a>
<h2 id="wq479">ISPF actions to perform before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq480">ISPF actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes ISPF migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p>
<p>None.</p>
<h2 id="wq481">ISPF actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes ISPF migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.<a id="idx795"></a><a id="idx796"></a><a id="idx797"></a><a id="idx798"></a><a id="idx799"></a><a id="idx800"></a></p>
<h3 id="ispf13">Review changes to ISPF panels for new allocation of non-SMS-managed
sequential data set</h3>
<p><strong>Description:</strong>  Before z/OS V1R13, the allocation option of the Data Set
Utility (OPT3.2) in Interactive System Productivity Facility (ISPF)
opened and closed new non-SMS-managed sequential data sets to write
end-of-file (EOF) markers.  Beginning in z/OS V1R13, this action is no longer performed for
new allocations through OPT3.2 and the new AL line command of the
Data Set List Utility (OPT3.4). As a result, the referenced date is
not set and is displayed with a value of ***None*** on the ISPF Data
Set Information panel and in the Referred column of the ISPF Data
Set list panel. This behavior is now consistent whether the data set
is SMS-managed or not.</p>
<table id="wq482" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>ISPF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if users expect to have the reference date
set when allocating a new non-SMS managed sequential data set using
ISPF option 3.2 or the AL line command of ISPF option 3.4.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> Notify users that the referred
date for a non-SMS data set is not set when the data set is allocated
using the ISPF Data Set Utility (option 3.2) or the ISPF Data Set
List Utility (option 3.4) AL line command.</p>
<p><strong>Reference information:</strong> For a description
of ISPF panel changes, see <cite></cite>.</p>
<h1 id="ah1jes2">JES2 migration actions</h1>
<p>This topic describes migration actions for base element JES2.</p><a id="idx801"></a>
<h2 id="wq483">JES2 actions to perform before installing z/OS V1R13</h2>
<p>This topic describes JES2 migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p><a id="idx802"></a><a id="idx803"></a><a id="idx804"></a><a id="idx805"></a>
<h3 id="exitchg">Update code to remove references to PDBLENG</h3>
<p><strong>Description:</strong>  Starting with z/OS V1R12, JES2 supports variable size PDDBs, though
the PDDBs generated in this release remain a fixed size.  Installation
exits that examine PDDBs or step through PDDBs using the compile time
length of the PDDB need to be updated to use a run time length field.
To facilitate locating an exit code that is assuming a fixed PDDB
size, the compile time length equate PDBLENG has been deleted.  Code
that used this compile time length should be updated to use the run
time field PDBSIZE to determine the size of the PDDB.  The field PDBSIZE
has correctly contained the length of the PDDB since z/OS V1R7 (the field existed in earlier releases
but was not consistently set).</p>
<table id="wq484" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
JES2.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
JES2.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if installation exits use PDBLENG equate.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> Before installing z/OS V1R13 JES2, review installation
exits for references to the field PDBLENG.  If any references are
found, the code needs to be updated to use the run time PDDB length
field PDBSIZE.</p>
<p><strong>Reference information:</strong> For a description
of how to write installation exits, see >z/OS JES2 Installation Exits</a>.</p>
<h3 id="pismult">Ensure calls to JES Property Information Services SSI can handle
multiple members</h3>
<p><strong>Description:</strong> In z/OS V1R11 JES2, the Initiator information function
of the JES Property Information Services SSI (SSI 82) returned information
for the local member only, even if multiple members matched the value
that was specified on the member filter. In z/OS V1R12 JES2, if information for multiple members
is requested by specifying wildcards on the member filter, the Initiator
information function will return information for all members that
match the filter request.</p>
<table id="wq485" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
JES2.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
JES2.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using the Initiator information
function of the JES Property Information Services SSI.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Before installing z/OS V1R13 JES2, ensure that all
calls to the Initiator information function of the JES Property Information
Services SSI (SSI 82) that request information for multiple members
can correctly handle information being returned for multiple members.</p>
<p><strong>Reference information:</strong> See >z/OS MVS Using the Subsystem Interface</a> for
more information.</p>
<h2 id="wq486">JES2 actions to perform before the first IPL of z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq487">JES2 actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes JES2 migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions. <a id="idx806"></a><a id="idx807"></a><a id="idx808"></a><a id="idx809"></a><a id="idx810"></a><a id="idx811"></a></p>
<h3 id="activ11">Activate z11 mode</h3>
<p><strong>Description:</strong> To take advantage of
the full-function level of z/OS V1R11
JES2, you must be in z11 mode. Activating z11 mode upgrades the JES2
checkpoint and enables JES2 functionality that is introduced in z/OS V1R11, including JOE data
area extensions supported by BERTs. z/OS V2R1
is planned to be the last release for which JES2 will support the
z2 level for checkpoint data sets. For more information on the JES2
functionality introduced in z/OS V1R11,
see the reference links below. <a id="idx812"></a><a id="idx813"></a></p>
<table id="wq488" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11
JES2.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
JES2 and z/OS V1R12 JES2.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to activate the full-function
level of z/OS V1R13 JES2 processing.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td> In order to activate z11 mode, all systems
in the JES2 MAS must be at z/OS V1R11
or later.  You may fall back to z2 mode, if necessary.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check <strong>JES2_Z11_Upgrade_CK_JES2</strong> to
determine if your system is ready to upgrade the JES2 checkpoint to
z11 mode. For more information, see >IBM Health Checker for z/OS: User&rsquo;s Guide</a>.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>After migrating to z/OS V1R11
JES2, or later, on all systems in your MAS, determine your z11 checkpoint
activation readiness:
<ol type="1">
<li>Use the <span class="pk">$D ACTIVATE </span>command. This command indicates if
activation to z11 mode will succeed.</li>
<li>Review your current utilization of BERT data to determine if there
are sufficient BERTS, as detailed in <a href="#checkbert">Check BERT utilization</a>.</li>
<li>If you issue the <span class="pk">$ACTIVATE,LEVEL=z11</span> command,
activation of LARGEDS support is required.</li>
<li>An additional <var class="pv">nnn</var> 4K records for CKPT1 is required
for z11 mode.</li></ol></li>
<li>Run the <span class="pk">JES2 $ACTIVATE</span> command <span>to verify
non-configuration changes that must be accommodated before going to
z11,</span> and to activate z11 mode following the considerations for
this command found in <cite></cite>>z/OS JES2 Commands</a>.
<div>
<div class="notetitle" id="wq490">Note:</div>
<div class="notebody">The SPOOLDEF LARGEDS=FAIL (default value) in JES2PARM parmlib
member is not supported in z11 mode. In z11 mode, on a COLD start,
JES2 defaults to LARGEDS=ALLOWED. However, you cannot issue the $ACTIVATE,LEVEL=z11
command in the environment of SPOOLDEF LARGEDS=FAIL.</div></div></li></ul>
<p>By default, JES2 restarts in the same mode (z2 or z11) as other
members of the MAS (if any are active) or the mode the last active
JES2 member was in when it came down. To restart JES2 in z2 mode,
specify UNACT on PARM=.  On a cold start JES2 starts in z11 mode unless
overridden by OPTSDEF COLD_START_MODE or UNACT parameter.</p>
<h4 id="checkbert">Check BERT utilization</h4>
<p>Before issuing the $ACTIVATE,LEVEL=z11 command, review the current
utilization of BERT data to determine whether there are sufficient
BERTs. Additional BERTs are needed for each SYSOUT data set that has
transaction data associated with it. These SYSOUT data sets can be
seen using SDSF by setting APPC ON and examining SYSOUT data sets
on the H and O panels; SYSOUT data sets with transaction data have
nontraditional JES2 job IDs. Consider increasing the number of BERTs
to correspond to two times the maximum number of transaction SYSOUT
data sets on the system. BERT utilization should be monitored after
the $ACTIVATE to z11 mode to ensure there are sufficient BERTs for
the jobs and SYSOUT in the MAS. There are several ways to determine
your current BERT usage.</p>
<ul>
<li>The $D CKPTSPACE,BERTUSE command displays a table of the types
of control blocks in BERTs and how many BERTs are used by each control
block type. The example below shows the output of the command:
<pre class="xmp"><code>$HASP852 CKPTSPACE  CURRENT BERT UTILIZATION
$HASP852            TYPE         COUNT  CB COUNT
$HASP852            -------- --------- ---------
$HASP852            INTERNAL        11         1,
$HASP852            JQE            211       108,
$HASP852            CAT            114        38,
$HASP852            WSCQ             1         1,
$HASP852            DJBQ             0         0,
$HASP852            JOE              0         0,
$HASP852            FREE           763         0</code></pre>In the example,
there are 108 JQEs that have a total of 211 BERTs associated with
them. This example is for a system in z2 mode and does not have any
BERTs associated with JOEs.</li>
<li>The $D ACTIVATE command displays the number of BERTs that are
needed for activation to z11 mode. This is the number of BERTs that
will be associated with JOEs after the $ACTIVATE. The example below
shows the output of the $D ACTIVATE command:       
<pre class="xmp"><code>$HASP895 $DACTIVATE
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 1100 BERTS AND BERT UTILIZATION IS 30
$HASP895     PERCENT.
$HASP895  -- CONTAINS 158 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 165 4K RECORDS.
$HASP895  -- REQUIRE 22 ADDITIONAL BERTS AND UTILIZATION
$HASP895     WOULD REACH 32 PERCENT.
$HASP895 z11 ACTIVATION WILL SUCCEED IF ISSUED FROM THIS MEMBER.</code></pre>In
the example, there are 22 additional BERTs that will be used after
the $ACTIVATE to z11 mode, for transaction data associated with JOEs.
<div>
<div class="notetitle" id="wq491">Note:</div>
<div class="notebody">When the SPOOLDEF LARGEDS=FAIL (default value) is in effect
in your JES2PARM parmlib member, the following message will be issued
by the $ACTIVATE command:
<pre class="xmp"><code>$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895     -- LARGEDS SUPPORT MUST BE ACTIVATED.</code></pre></div></div></li>
<li>A general history of BERT usage can be obtained by using the $JD
HISTORY(BERT) command or by using the SDSF RM panel. This displays
the usage of BERTs after the system was IPLed. The example below shows
the output of the $JD HISTORY(BERT) command: 
<pre class="xmp"><code>$HASP9130 D HISTORY
$HASP9131 JES2 BERT     USAGE HISTORY
DATE     TIME        LIMIT    USAGE      LOW     HIGH  AVERAGE
-------- -------- -------- -------- -------- -------- --------
2009.086 16:00:00     1100      337      337      337      337
2009.086 15:50:09     1100      337      125      337      192</code></pre></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For a list of the enhancements introduced in z/OS V1R11 for z11 mode, see >z/OS Introduction and Release Guide</a>.</li>
<li>For $ACTIVATE, $D ACTIVATE, $D CKPTSPACE and $JD HISTORY command
details, see >z/OS JES2 Commands</a>.</li></ul>
<h1 id="al1jes3">JES3 migration actions</h1>
<p>This topic describes migration actions for optional feature JES3.</p><a id="idx814"></a>
<h2 id="wq492">JES3 actions to perform before installing z/OS V1R13</h2>
<p>This topic describes JES3 migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.<a id="idx815"></a><a id="idx816"></a><a id="idx817"></a><a id="idx818"></a></p>
<h3 id="dlogsplit">Modify code that depends on the format of suppressed split
messages in the DLOG</h3>
<p><strong>Description:</strong> The JES3 DLOG facility was introduced
for tracking all message activity in a sysplex. It uses an MCS extended
console to receive the messages and reformats them in the JES3 format.
When these messages are longer than can be formatted into a single
line, they are split into two lines.  Prior to z/OS V1R13 JES3, longer messages having a receive
ID were formatted differently if they were suppressed by the message
processing facility (MPF).  Beginning with z/OS V1R13 JES3, all suppressed messages with a
receive ID are split in the same manner.</p>
<p>The following DLOG excerpt shows how a suppressed message (XXX100I)
was split prior to z/OS V1R13
JES3:</p>
<pre class="xmp"><code>          10250 1143599  SY1 R= XXX33913 ICH70001I IBMUSER  LAST ACCESS AT 11:39:46 ON MONDAY, NOVEMBER 1, 2010
          10250 1144001  SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=11.44.00
MLG       10250 1144004 &amp;SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
MLG       10250 1144004 &amp;SY1 R= XXX3391378901234567890123456789012345678901234567890123456789012345
          10250 1144004  SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=11.44.00</code></pre><p class="indatacontent">The
following DLOG excerpt shows how a suppressed message (XXX100I) is
split beginning with z/OS V1R13
JES3:</p>
<pre class="xmp"><code>          10305 1000486  SY1 R= XXX33913 ICH70001I IBMUSER  LAST ACCESS AT 09:57:46 ON MONDAY, NOVEMBER 1, 2010
          10305 1000488  SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=10.00.48
MLG       10305 1000494 &amp;SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
MLG       10305 1000494 &amp;SY1 R= XXX33913 78901234567890123456789012345678901234567890123456789012345
          10305 1000494  SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=10.00.49   </code></pre><a id="idx819"></a><a id="idx820"></a>
<table id="wq493" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
JES3.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
JES3 or z/OS V1R11 JES3.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation has a code dependency
on the format of messages in the JES3 DLOG.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Ensure that any dependency
on DLOG message formats are examined and corrected.</p>
<p><strong>Reference information:</strong> For more information,
see the &quot;Message Format&quot; chapter in >z/OS JES3 Messages</a>.</p>
<h2 id="wq494">JES3 actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes JES3 migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.<a id="idx821"></a><a id="idx822"></a><a id="idx823"></a><a id="idx824"></a><a id="idx825"></a><a id="idx826"></a></p>
<h3 id="autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</h3>
<p><strong>Description:</strong> Before z/OS V1R13, a DOWN response to message IXC102A issued
for a JES3 local processor required operations to enter the <span class="pk">*S
main,FLUSH</span> command. Without the <span class="pk">*S main,FLUSH</span> command,
jobs on the local were held up until the local processor was reconnected.</p>
<p>Starting in z/OS V1R13,
JES3 flushes the active jobs on the local processor automatically
as soon as the operator responds to message IXC102A. This automatic
flush eliminates the step of issuing the command and reduces the time
gap between the local processor being removed from the sysplex and
job recovery actions.</p>
<p>In z/OS V1R13 JES3 and later
releases, if you run the <span class="pk">*S main,FLUSH</span> command in response
to the XCF messages, the command will have no effect because the affected
jobs will have already been flushed by the new automatic processing.</p>
<p><a id="idx827"></a><a id="idx828"></a></p>
<table id="wq495" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
JES3 or z/OS V1R11 JES3.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid redundant <span class="pk">*S
main,FLUSH</span> commands.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you want to avoid redundant <span class="pk">*S
main,FLUSH</span> commands, remove the <span class="pk">*S main,FLUSH</span> command
from all automated procedures or operating procedures.</p>
<p><strong>Reference information:</strong> >z/OS JES3 Messages</a>.</p>
<h3 id="moddatlorec">Modify code that uses DATLOREC and DATINPTR (IATYDAT) as a
 programming interface</h3>
<p><strong>Description:</strong> When a job's JCL contains in-stream
data sets, the  in-stream data is stored in multi-record files apart
from the JESJCLIN file.  These files are located by SYSIN pointer
records that are written into a job's JESJCLIN file by input service.
 Prior  to z/OS V1R12 (without
APAR OA34642), SYSIN pointer records were included in the JESJCLIN
file's record count which is saved in DATLOREC (IATYDAT).  In z/OS V1R12, z/OS V1R11, and z/OS V1R10
(with APAR<span> OA33040</span>), the SYSIN pointer records were
not included  in the record count for JESJCLIN files.  <span>With
APAR OA34642 applied,</span> a new flag, DATCTLRD (IATYDAT),  will be
on for any record, including SYSIN pointer records, that are not included
in a file's record count.  <a id="idx829"></a><a id="idx830"></a></p>
<table id="wq496" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12
JES3, z/OS V1R11 JES3, and z/OS V1R10 JES3 with the PTF for
APAR OA34642 applied.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
JES3 or z/OS V1R11 JES3 without
the PTF for APAR OA34642 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use DATLOREC and DATINPTR (IATYDAT)
as a programming interface.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Before applying the PTF for
APAR OA34642, examine and modify any code that uses DATLOREC and DATINPTR
(IATYDAT) as a programming interface.  Note that IATYDAT is an internal
JES3 control block that resides on spool and that this change affects
only JESJCLIN data sets.</p>
<p><strong>Reference information:</strong> For more information,
see >z/OS JES3 Initialization and Tuning Guide</a>.</p>
<h3 id="jes3msg">Update automation that handles message IAT3100</h3>
<p><strong>Description:</strong> In the text of message IAT3100,
a space has been added between the "z" and the release identifier.
In z/OS V1R11 and z/OS V1R12, the text for message
IAT3100 appeared as in the following example:</p>
<pre class="xmp"><code>IAT3100 JES3 z1.12.0   SYSTEM  HOTSTART ON 2011.304 AS SY1 </code></pre><p class="indatacontent">Starting
with z/OS V1R13, the text appears
as in the following example:</p>
<pre class="xmp"><code>IAT3100 JES3 z 1.13.0  SYSTEM  HOTSTART ON 2011.304 AS SY1   </code></pre><p class="indatacontent">If
your message automation for JES3 depends on the message text instead
of the message number, your JES3 automation routines might be affected.<a id="idx831"></a><a id="idx832"></a></p>
<table id="wq497" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
JES3.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
JES3 or z/OS V1R11 JES3.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation routines that examine
the message text instead of the message number.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Change your automation routines
to account for the additonal space.</p>
<p><strong>Reference information:</strong> For more information,
see <cite></cite>.</p>
<h2 id="wq498">JES3 actions to perform after the first IPL of z/OS V1R13</h2>
<p>None.</p>
<h1 id="am1lenv">Language
Environment migration actions</h1>
<p>This topic describes migration actions for base element Language Environment.</p><a id="idx833"></a>
<h2 id="wq499">Language
Environment actions to perform before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq500">Language
Environment actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes Language
Environment migration actions that you can perform after you
have installed z/OS V1R13 but
before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx834"></a><a id="idx835"></a><a id="idx836"></a><a id="idx837"></a><a id="idx838"></a><a id="idx839"></a>
<h3 id="am3le2">Determine the impact of added and changed runtime options</h3><a id="idx840"></a><a id="idx841"></a><a id="idx842"></a>
<p><strong>Description:</strong> Periodically, Language Environment introduces
new runtime options, adds new suboptions to existing runtime options,
and changes the defaults of runtime options. For z/OS V1R12 and z/OS V1R13,
no runtime options were changed or new suboptions added. Therefore,
no migration action is required for your migration to z/OS V1R13.</p>
<h3 id="am3le2a">Update the CSD based on the newest CEECCSD</h3>
<p><strong>Description:</strong> Each release, Language Environment adds
or deletes load modules in the CICS system
definition (CSD) file. Thus, you should update the file each release
using the program definitions found in members CEECCSD and CEECCSDX
found in the SCEESAMP data set. <span>The CSD samples provided
by Language Environment (CEECCSD
and CEECCSDX) at the latest release may be used for systems at lower
releases that can co-exist with this level of z/OS.</span></p><a id="idx843"></a><a id="idx844"></a>
<table id="wq501" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>CICS.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Update the CSD
file using the program definitions in member CEECCSD (and member CEECCSDX
if using CICS TS V3.1 or later
releases) found in the <samp class="xph">hlq</samp>.SCEESAMP data set.</p>
<div>
<div class="notetitle" id="wq502">Note:</div>
<div class="notebody"> The
group containing the Language
Environment runtime routines must be in the group list used during CICS startup.</div></div>
<p><strong>Reference information:</strong> See >z/OS Language Environment Run-Time Application Migration Guide.</a></p>
<h3 id="am3le2b">Update Language
Environment load modules in the LPA</h3>
<p><strong>Description:</strong> Each release you must update
the Language Environment load
modules that you make accessible through the link pack area (LPA).
In addition, each release you should review your list of Language Environment load
modules in the LPA to determine if it's still suitable. <a id="idx845"></a><a id="idx846"></a></p>
<table id="wq503" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you need to make modules accessible
through the link pack area (LPA).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review Language Environment load
modules in the LPA.</p>
<p>To move load modules into the LPA, use the following sample members
in the CEE.SCEESAMP data set:</p>
<ul>
<li><em>AFHWMLP2:</em> This is a sample of all Language Environment Fortran
component modules eligible for the LPA.</li>
<li><em>CEEWLPA:</em> This is a sample of a PROG<var class="pv">xx</var> member
of SYS1.PARMLIB that includes all Language Environment CEE-prefixed runtime modules
eligible for the LPA (that is, all Language Environment base modules) except the callable
services stubs.</li>
<li><em>CELQWLPA:</em> This is a sample for AMODE 64
runtime support.</li>
<li><em>EDCWLPA:</em> This is a sample of a PROG<var class="pv">xx</var> member
of SYS1.PARMLIB that includes all Language Environment EDC-prefixed and CEH-prefixed
runtime modules eligible for the LPA (that is, all XL C/C++ component
modules) except locales and code page converters.</li>
<li><em>IBMALLP2 (or IBMPLPA1 for Enterprise PL/I for z/OS):</em> This is a sample of
all Language Environment PL/I
component modules eligible for the LPA.</li>
<li><em>IGZWMLP4:</em> This is a sample of all Language Environment COBOL
component modules eligible for the LPA.</li></ul>
<p>To see which modules are eligible for the LPA, refer to >z/OS Language Environment Customization</a>.
The modules listed there can be put in the LPA or extended LPA (ELPA)
depending on their RMODE value:</p>
<ul>
<li>If the RMODE is ANY, the module can reside in the LPA or in the
ELPA (above or below the 16 MB line).</li>
<li>If the RMODE is 24, the module can reside only in the LPA (below
the 16 MB line).</li></ul>
<p>If you are considering placing the modules listed in >z/OS Language Environment Customization</a> in
the LPA or the ELPA, then IBM recommends
that you place the SCEELPA data set in the LPA list (LPALST<var class="pv">xx</var>).
SCEELPA contains Language
Environment load modules that are reentrant, that reside above
the 16 MB line, and that are heavily used by z/OS.</p>
<p>In >z/OS Language Environment Customization</a> you
will also see tables of modules eligible for the LPA and the ELPA
above and beyond what is found in the SCEELPA data set. You will need
to use the dynamic LPA or MLPA approach to move these modules into
the LPA or ELPA. You do not need to include recommended modules if
they contain functions your installation does not use. Language Environment modules
not listed in these tables can be moved into the LPA or ELPA at your
discretion.</p>
<p><strong>Reference information:</strong> See the table &quot;Language Environment sample
IEALPAnn or PROGxx members in <var class="pv">hlq</var>.SCEESAMP&quot; for the list
of sample members and their changed content in >z/OS Language Environment Customization</a>.
The table contains a list of eligible load modules for:</p>
<ul>
<li>Language Environment base
modules</li>
<li>Language Environment XL
C/C++ component modules</li>
<li>Language Environment COBOL
component modules</li>
<li>Language Environment Fortran
component modules</li>
<li>Language Environment PL/1
component modules</li></ul>
<h3 id="ceeprmset">Convert to CEEPRMxx to set system-level default runtime
options</h3>
<p><strong>Description:</strong> In the IBM z/OS V1.12
Software Announcement 210-235 dated 22 July 2010, IBM announced plans to remove, in a future release,
the capability to change the default Language Environment runtime options settings using
SMP/E installable USERMODs.  If you are still using assembler modules
to specify your installation-wide default runtime options (CEEDOPT,
CEECOPT, or CELQDOPT), IBM recommends
that you convert to using the CEEPRM<var class="pv">xx</var> parmlib member to
set your system-level default Language Environment runtime options. z/OS V1R13 is planned to be the
last release to support the SMP/E USERMOD to customize the LE Run-time
options.<a id="idx847"></a><a id="idx848"></a><a id="idx849"></a></p>
<table id="wq504" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.
(Previewed in IBM z/OS V1.12 Software Announcement
210-235, 22 July 2010.)</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> No, but recommended because even though the
runtime option usermods continue to be supported in this release, IBM plans to remove this functionality
in a future release of z/OS.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use CEE_USING_LE_PARMLIB to check that default Language Environment runtime
options are set within a CEEPRM<var class="pv">xx</var> parmlib member.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you are no longer using the Language Environment runtime option assembler usermods,
you have no further action.</li>
<li>If you are using the Language Environment runtime option assembler usermods,
you should now convert to CEEPRM<var class="pv">xx</var>. Taking this step now
will eliminate a migration action in a future release.</li></ul>
<p><strong>Reference information:</strong> For details about
specifying CEEPRM<var class="pv">xx</var>, see >z/OS Language Environment Customization</a>.</p>
<h3 id="dceecom">Examine programs that read output when a D CEE command is issued</h3>
<p><strong>Description:</strong> Starting in z/OS V1R12, changes are made to the Language Environment runtime
options report when a D CEE command is issued. Before z/OS V1R12, the Language Environment runtime
options report displayed all suboptions, even if they were not explicitly
set for any runtime option that was specified. Starting in z/OS V1R12, when a valid option
is specified with a parmlib member or a SETCEE command, only the suboptions
specified are displayed when a D CEE command is issued. A comma is
displayed as a place holder for those suboptions not specified.<a id="idx850"></a><a id="idx851"></a><a id="idx852"></a></p>
<table id="wq505" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have an application that reads the
output of a D CEE command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<p>Examine any programs that read the output of a D CEE command to
ensure compatibility with the updated runtime options report. Commas
are now displayed for any suboptions that are not explicitly specified
in a parmlib member or with a SETCEE command.</p>
<p>For example, if the following SETCEE command is issued:  </p>
<pre class="xmp"><code>SETCEE CEEDOPT,ALL31,ANYHEAP(4K),FILETAG(,AUTOTAG)</code></pre><p class="indatacontent"> a
subsequent D CEE,CEEDOPT command displays the following:</p>
<pre class="xmp"><code>CEE3745I 09.32.13 DISPLAY CEEDOPT
NO MEMBERS SPECIFIED
LAST WHERE SET                           OPTION
-----------------------------------------------------------------------
SETCEE command                             ALL31()
SETCEE command                             ANYHEAP(4096,,,)
SETCEE command                             FILETAG(,AUTOTAG)</code></pre>
<p><strong>Reference information:</strong> For more information,
see >z/OS Language Environment Customization</a> and >z/OS MVS System Commands</a>.</p>
<h3 id="nonover">Set runtime options as overrideable or nonoverrideable in CEEPRMxx
parmlib member</h3>
<p><strong>Description:</strong> Before z/OS V1R12, all runtime options specified in a CEEPRM<var class="pv">xx</var> parmlib
member were overrideable by default. Beginning with z/OS V1R12, you can set runtime options as overrideable
or nonoverrideable in the CEEPRM<var class="pv">xx</var> parmlib member or with
a SETCEE command using the OVR or NONOVR attribute. The ability
to specify an option as overrideable or nonoverrideable removes a
barrier to using CEEPRM<var class="pv">xx</var>.<a id="idx853"></a><a id="idx854"></a></p>
<table id="wq506" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended so you can eliminate use
of the assembler language usermods to specify installation-wide runtime
options, and use parmlib member CEEPRM<var class="pv">xx</var> instead.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use CEE_USING_LE_PARMLIB to verify use of the
CEEPRM<var class="pv">xx</var> parmlib member.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong>  Set runtime options as
overrideable or nonoverrideable in the CEEPRM<var class="pv">xx</var> parmlib member
or by issuing the SETCEE command using the OVR or NONOVR attribute.</p>
<p>Now that runtime options can be specified as overrideable or nonoverrideable
in a CEEPRM<var class="pv">xx</var> parmlib member, and with a SETCEE command,
you can eliminate the use of assembler language usermods to specify
installation-wide runtime options.</p>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about specifying a CEEPRM<var class="pv">xx</var> parmlib member,
see >z/OS Language Environment Customization</a>.</li>
<li>For the updated CEEPRM00 sample parmlib member, which includes
every option specified as overrideable, see the CEE.SCEESAMP data
set.</li></ul>
<h2 id="wq507">Language
Environment actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes Language
Environment migration actions that you can perform only after
you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx855"></a><a id="idx856"></a><a id="idx857"></a><a id="idx858"></a><a id="idx859"></a><a id="idx860"></a>
<h3 id="leclerop">Examine programs that read output from a CICS CLER transaction</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, the Language Environment runtime options report displayed
from the CICS CLER transaction
is changed. The report is modified to have a wider LAST WHERE SET
column to accommodate longer values, such as &quot;Installation Non-overrideable.&quot;
In addition, the report heading OPTIONS is changed to OPTION to match
the other runtime options reports.<a id="idx861"></a></p>
<table id="wq508" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have an application that reads the
output of a CICS CLER transaction.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Examine programs that read
the output of a CICS CLER transaction
to ensure compatibility with the updated CLER runtime options report.
The LAST WHERE SET column is now wider and the OPTIONS heading is
changed to OPTION. The following is a subset of the new report to
show the formatting changes:</p>
<pre class="xmp"><code>LAST WHERE SET                 OPTION
-----------------------------  -----------------------------------------------
Installation default             ABPERC(NONE)
Installation default             ABTERMENC(ABEND)
Installation default           NOAIXBLD</code></pre>
<p><strong>Reference information:</strong> For more information,
see >z/OS Language Environment Programming Guide</a> and >z/OS Language Environment Debugging Guide</a>.</p>
<h3 id="convtbl">Use Unicode Services to create conversion tables</h3>
<p><strong>Description:</strong> Beginning with z/OS V1R12, the C/C++ runtime library will no longer
include any ucmap source code or genxlt source code for character
conversions now being performed by Unicode Services. <a id="idx862"></a></p>
<table id="wq509" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the iconv() family of functions
to test to a &quot;known conversion result&quot;and experience testcase
failures. Also, if you use custom conversion tables replacing those
listed in either ucmapt.lst or genxlt.lst.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>If you use customized conversion tables, you should now generate
custom Unicode Services conversion tables.</li>
<li>If you use the iconv() family of functions testing to a &quot;known
conversion result&quot; and experience test case failures, you need
to update your expected results to the new conversion results.</li>
<li>If you want to create custom conversion tables involving any of
the CCSIDs related to the conversion table source no longer being
shipped, you should now generate custom Unicode Services conversion
tables instead of custom Language Environment conversion tables.</li></ul>
<p>The <var class="pv">installation prefix</var>.SCEEUMAP data set will no longer
be shipped.</p>
<p>The <samp class="xph">/usr/lib/nls/locale/ucmap</samp> HFS directory will no
longer be shipped.</p>
<div>
<div class="notetitle" id="wq510">Note:</div>
<div class="notebody">The _ICONV_TECHNIQUE environment variable must be
set to the same technique search order value used for the customized
Unicode Services table in order for the iconv() family of functions
to use the customized Unicode Services table. For example, if you
want the iconv() family of functions to use a user-defined
Unicode Services table with a technique search order of 2, the _ICONV_TECHNIQUE
environment variable should be set to 2LMREC.</div></div>
<p><strong>Reference information:</strong> For information about
how to generate and use custom Unicode Services conversion tables,
see >z/OS Unicode Services User&rsquo;s Guide and Reference</a>.</p>
<h1 id="ab1bser">Library Server migration actions</h1>
<div>
<div class="head2"><a href="#wq511" class="ptoclink">Library Server actions to perform before installing z/OS V1R13</a></div>
<div class="head2"><a href="#libsb1i" class="ptoclink">Library Server actions to perform before the first IPL of z/OS V1R13</a></div>
<div class="head3"><a href="#ab3conf" class="ptoclink">Copy Library Server configuration files</a></div>
<div class="head3"><a href="#ab3note" class="ptoclink">Copy Library Server notes files</a></div>
<div class="head2"><a href="#wq514" class="ptoclink">Library Server actions to perform after the first IPL of z/OS V1R13</a></div></div>
<p>This topic describes migration actions for base element Library
Server.</p><a id="idx863"></a>
<h2 id="wq511">Library Server actions to perform before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="libsb1i">Library Server actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes Library Server migration actions that you
can perform after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx864"></a><a id="idx865"></a><a id="idx866"></a><a id="idx867"></a><a id="idx868"></a><a id="idx869"></a>
<h3 id="ab3conf">Copy Library Server configuration files</h3>
<p><strong>Description:</strong> The Library Server configuration
files (<samp class="xph">bookmgr.80</samp>, <samp class="xph">booksrv.80</samp>) contain information
about your environment and preferences. The information in <samp class="xph">bookmgr.80</samp> includes
the names of bookshelf lists for bookshelves in MVS data sets and the names of the HFS directories
that Library Server reads and writes during execution. The information
in <samp class="xph">booksrv.80</samp> includes the HFS directory names of book
collections, shelves, and bookcases. There are default values but
normally you would customize them. In order to bring the customized
values over to your new system, you have to copy them. (Note that
port number suffix .80, used in <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
is an example. Your port number suffix might be different.)</p>
<table id="wq512" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve your Library
Server configuration.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Copy your current (customized)
configuration files, usually <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
to your new system and add any configuration parameters that are
new since the z/OS release
from which you are migrating. Otherwise Library Server will run
with default values, not the values you're used to. A suggested (but
not required) place for these configuration files is <samp class="xph">/etc/booksrv</samp>.
Library Server will also search <samp class="xph">/etc</samp> and the original cgi-bin
for them. If you place the files in any other directory, use the EPHConfigPath
environment variable to tell Library Server where to find them.</p>
<p><strong>Reference information:</strong> For a complete description
of each parameter of the Library Server configuration files, see >z/OS Program Directory</a>.</p>
<h3 id="ab3note">Copy Library Server notes files</h3>
<p><strong>Description:</strong> Users can make comments in book
topics by creating notes that are appended to the end of each topic. <a id="idx870"></a>If you do not copy
these notes to the new system, they will be lost.</p>
<table id="wq513" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve notes from release
to release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Copy all the files from your
existing notes directory to the new one. The default directory for
saving book notes is <samp class="xph">/usr/lpp/booksrv/public/bookmgr/notes</samp>.
You can override this default by specifying a directory on the NOTEDIR
parameter of the <samp class="xph">bookmgr.80</samp> configuration file.</p>
<p><strong>Reference information:</strong> For a complete description
of each parameter of the Library Server configuration files, see >z/OS Program Directory</a>.</p>
<h2 id="wq514">Library Server actions to perform after the first IPL of z/OS V1R13</h2>
<p>None.</p>
<h1 id="ao1rmf">RMF migration actions</h1>
<p>This topic describes migration actions for optional feature Resource Measurement Facility&trade; (RMF).</p><a id="idx871"></a>
<h2 id="wq515">RMF actions to perform
before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq516">RMF actions to perform
before the first IPL of z/OS V1R13</h2>
<p>This topic describes RMF migration
actions that you can perform after you have installed z/OS V1R13 but before the first
time you IPL. These actions might require the z/OS V1R13 level of code to be installed but do
not require it to be active.</p><a id="idx872"></a><a id="idx873"></a><a id="idx874"></a><a id="idx875"></a><a id="idx876"></a><a id="idx877"></a>
<h3 id="msgerb81">Check your automation for Monitor III messages ERB812I and
ERB813I</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, RMF Monitor
III messages ERB812I (introduced in z/OS V1R11) and
ERB813I are issued as single line WTO messages. Before z/OS V1R13, for those messages,
there could have been multiple WTOs if the message length was longer
than 69 characters. If you use an automation product that processes
these messages, check the algorithm, and, if required, adapt it to
the new message output. <a id="idx878"></a> <a id="idx879"></a></p>
<table id="wq517" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation products for RMF messages ERB812I and ERB813I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you use an automation
product that processes RMF Monitor
III messages ERB812I and ERB813I, check the algorithm because the
output format of these messages changes in z/OS V1R13 RMF.
Message ERB812I was introduced in z/OS V1R11.</p>
<p>Below are examples of the old output format and the new output
format for these messages. Check the code of your automation product
to determine if you need to adapt it to the new message output format.</p>
<p><span class="bold-italic">Old output format:</span>&nbsp;</p>
<pre class="xmp"><code>ERB812I III: MONITOR III DATA RECORDING INTO DATA SET 'RMF.MONITOR3.D
ERB812I III:     ATASET3.SYSE' STOPPED
ERB813I III: ACTIVE MONITOR III DATA SET IS NOW 'RMF.MONITOR3.DATASET
ERB813I III:     4.SYSE'</code></pre>
<p><span class="bold-italic">New output format:</span>&nbsp;</p>
<pre class="xmp"><code>ERB812I III: MONITOR III DATA RECORDING INTO DATA SET 'RMF.MONITOR3.DATASET3.SYSE' STOPPED
ERB813I III: ACTIVE MONITOR III DATA SET IS NOW 'RMF.MONITOR3.DATASET4.SYSE'</code></pre>
<p><strong>Reference information:</strong> For further information
see >z/OS RMF Messages and Codes</a>.</p>
<h2 id="wq518">RMF actions to perform
after the first IPL of z/OS V1R13</h2>
<p>This topic describes RMF migration
actions that you can perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these
actions.</p><a id="idx880"></a><a id="idx881"></a><a id="idx882"></a><a id="idx883"></a><a id="idx884"></a><a id="idx885"></a>
<h3 id="rmflater">Use an RMF Monitor III
reporter version equal to or later than your RMF Monitor III gatherer version</h3>
<p><strong>Description:</strong> To avoid problems when reporting
Monitor III data, use an RMF reporter
version that is equal to or later than the latest RMF gatherer version used to collect the data to
be reported. For example, it is safe to use an RMF reporter version from z/OS V1R13 for data collected with an RMF gatherer from z/OS V1R11, but not vice versa.  <a id="idx886"></a></p>
<p>Mixed (and therefore problematic) levels of collected data can
occur in the following scenarios: </p>
<ul>
<li><em>Single system:</em> You install and test a
new release, then fall back to an earlier one; your data sets might
contain data collected with different versions of the RMF gatherer.</li>
<li><em>Sysplex:</em> You migrate to a new release
on one system in a sysplex but try to use an earlier reporter version
from another system to report on the migrated system's data.</li></ul>
<table id="wq519" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you had planned to use an earlier-level RMF reporter on data that was collected
with a later-level RMF gatherer.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>See &quot;Steps to take&quot; below.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Always use an RMF Monitor III reporter version that is equal to
or later than the gatherer version used to collect the data from which
you want to produce a report.</p>
<div>
<div class="notetitle" id="wq520">Note:</div>
<div class="notebody">Monitor III notifies users by issuing information
message ERB948I when a reporter session is started on a system in
a sysplex that is not running with the highest RMF level available in the sysplex. The message helps
users to avoid reporting problems.</div></div>
<p><strong>Reference information:</strong> For more information
about Monitor III commands, see >z/OS RMF User&rsquo;s Guide</a>.</p>
<h3 id="psdrept">Determine need of SMF data collection for Postprocessor
Serialization Delay report</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, RMF provides
a new Postprocessor Serialization Delay report. If you do not need
this report, <span>you should turn off data collection for
SMF record 72 subtype 5.</span><a id="idx887"></a><a id="idx888"></a></p>
<table id="wq521" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you do not want to collect
SMF data for the Postprocessor Serialization Delay report.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Determine if you want to use
the new Postprocessor Serialization Delay report. SMF data required
for this report is gathered by default. If you do not want to use
this report, you should suppress the SMF data collection for the new
record type 72 subtype 5. You achieve this by specifying NOTYPE for
this SMF record type in the SMF parmlib member SMFPRM<var class="pv">xx</var>.</p>
<p>Another method to suppress the data gathering of record
72.5 for the Serialization Delay report is to use the SUBSYS parameter
in the SMFPRM<var class="pv">xx</var> parmlib member for the STC subsystem (started
tasks, where RMF is one of them).
To exclude data gathering for SMF record 72.5, specify <span class="pk">SUBSYS(STC,NOTYPE(72(5)),
... )</span>.</p>
<p>The SUBSYS specification overrides the SYS specification.
So for example, if you have defined <span class="pk">SYS(TYPE(...,72,...))</span> in
your SMFPRM<var class="pv">xx</var> parmlib member, you can use <span class="pk">SUBSYS(STC,
NOTYPE(72(5)))</span> to make exceptions to your SYS specification and
just exclude gathering of SMF record 72.5 for started tasks like RMF.</p>
<p><strong>Reference information:</strong> For details about
specifying SMF data collection, see >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h3 id="irqueue">Retrieve the distribution of the IN-READY QUEUE</h3>
<p><strong>Description:</strong> Before z/OS V1R12, the Postprocessor CPU Activity report
provided a graphical representation of how many address spaces have
been waiting in the IN-READY QUEUE. Starting with z/OS V1R12, the DISTRIBUTION OF IN-READY QUEUE is
replaced by a more precise DISTRIBUTION OF WORK UNIT QUEUE representation.</p>
<p>You can retrieve the old IN-READY QUEUE distribution values using
the corresponding Overview control statements and display a numerical
representation in the Postprocessor Overview report or a graphical
representation in the Spreadsheet Reporter. <a id="idx889"></a><a id="idx890"></a></p>
<table id="wq522" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to retrieve the old IN-READY
QUEUE information as presented in the CPU Activity reports earlier
than z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use the available OCPU1, OCPU2, ...
OCPU80 Overview control statements to retrieve the information presented
in the DISTRIBUTION OF IN-READY QUEUE of the CPU Activity reports
earlier than z/OS V1R12. With
these statements, you can produce either a numerical representation
in the Postprocessor Overview report or you can use the RMF Spreadsheet Reporter to see a
graphical representation:  Select the <span class="bold-italic">System
Overview Report</span> spreadsheet macro and click on the <span class="bold-italic">OneCpuCont</span> sheet to see the graphical output.</p>
<p><strong>Reference information:</strong> For details about
using Overview conditions for the Overview Report and the Spreadsheet
Reporter, see >z/OS RMF User&rsquo;s Guide</a>.</p>
<h1 id="ap1sdsf">SDSF migration actions</h1>
<p>This topic describes migration actions for optional feature SDSF.</p><a id="idx891"></a>
<h2 id="wq523">SDSF actions to perform before installing z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq524">SDSF actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes SDSF migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx892"></a><a id="idx893"></a><a id="idx894"></a><a id="idx895"></a><a id="idx896"></a><a id="idx897"></a>
<h3 id="ax3exit">Review and reassemble user exit routines</h3>
<p><strong>Description:</strong> If you have written user exit
routines, review them to ensure they are still appropriate for the
current environment, and make changes as necessary. <a id="idx898"></a><a id="idx899"></a>All user exit
routines must be reassembled with the z/OS V1R13
level of the SDSF macro library.</p>
<table id="wq525" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if user exit routines are in use.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review user exit routines
to ensure they are appropriate for z/OS V1R13.
Make changes as necessary. Regardless of whether you have made changes,
reassemble the user exit routines with the z/OS V1R13 level of the SDSF macro library.</p>
<p>Tip: A PROPLIST statement, along with PROPERTY
statements, both in the ISFPRM<var class="pv">xx</var> parmlib member, defines
customized values for certain SDSF properties. It provides an alternative
to writing user exit routines to customize those properties. A user
exit routine that customizes the same property as a PROPERTY statement
overrides the value on the PROPERTY statement.</p>
<p><strong>Reference information:</strong> See >z/OS SDSF Operation and Customization</a>.</p>
<h3 id="ax3assm">Use dynamic statements for ISFPARMS to avoid reassembly</h3>
<p><strong>Description:</strong> ISFPARMS in SDSF is used for
specifying global options, the format of panels, and security for
SDSF functions.  SDSF provides two alternatives for ISFPARMS:</p>
<ul>
<li>Assembler macros that you define, assemble, and then link into
the SDSF load library. This is the original format for defining ISFPARMS
and it continues to be supported for compatibility.</li>
<li>Dynamic statements, which are in parmlib member ISFPRM<var class="pv">xx</var>.
Dynamic statements are the recommended format. They are easier to
code and are more dynamic than the assembler macros; they can be updated
without reassembling or link-editing. The statements are processed
by an SDSF server, which is controlled by MVS operator
commands.</li></ul><a id="idx900"></a>
<table id="wq526" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid the migration action
of reassembling your customized ISFPARMS for each z/OS release.  (If you do not use dynamic statements
for ISFPARMS, reassembly of your customized ISFPARMS is required on
each release.)</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check SDSF_ISFPARMS_IN_USE to verify that
SDSF dynamic statements in ISFPRM<var class="pv">xx</var> are being used rather
than the assembler macros. If the check determines that the assembler
macro ISFPARMS is in use instead, and that it has been modified, the
check generates an exception. If the assembler macro ISFPARMS is in
use but it has not been modified, so that all defaults are in effect,
the check does not generate an exception.
<p>SDSF registers this check
with the IBM Health Checker
for z/OS infrastructure when
the SDSF server address space is initialized. However, one of the
items this check verifies is that the SDSF server itself is in use,
so you have to manually add this check (particularly if you do not
use the SDSF server) so that the IBM Health
Checker for z/OS infrastructure
will invoke the check. To add the check, put the following statement
in your PROG<var class="pv">xx</var> parmlib member: <samp class="xph">EXIT ADD EXITNAME(HZSADDCHECK)
MODNAME(ISFHCADC)</samp>.</p>
<p>SDSF health checks are distributed
in ISF.SISFLOAD for installations running SDSF in the LNKLST. The
checks are also distributed in ISF.SISFLINK for installations that
do not run SDSF in the LNKLST. For those installations, ISF.SISFLINK
must be added to the LNKLST.</p>
<p></p>
<div>
<div class="notetitle" id="wq527">Note:</div>
<div class="notebody"> To avoid
a possible ABEND 290 <span>with reason code 02014007</span> issued
by HZSADDCK: 
<ul>
<li>Make sure that you specify the proper check routine name. The
check routine module must be in an APF-authorized library. The system
must be able to locate the check routine within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or
the LNKLST.</li>
<li>Make sure that you specify the proper message table name. The
message table module must be in an APF-authorized library. The system
must be able to locate the message table within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or
the LNKLST.</li></ul></div></div></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you are already using dynamic
statements for ISFPARMS<var class="pv">xx</var>, there is no migration action to
perform.</p>
<p>If you are using assembler macros for ISFPARMS, do one of the following:</p>
<ul>
<li>Convert your existing ISFPARMS to dynamic statements by using
a conversion utility that you invoke with the ISFACP command.</li>
<li>Reassemble your customized ISFPARMS for use with z/OS V1R13.  Reassembly must be done whenever you
change your z/OS release. Before
reassembling ISFPARMS, you might want to update it for new function.
The assembler ISFPARMS cannot be shared with any other release of
SDSF. Only use ISFPARMS for the release on which it is assembled. 
<div>
<div class="notetitle" id="wq528">Note:</div>
<div class="notebody">Sample job ISFPARME has been removed from the samples
supplied with SDSF. This job contained SMP/E control statements to
receive the sample assembler macro ISFPARMS as a user modification
(usermod). If you have an SMP/E usermod that specifies modifications
to assembler macro ISFPARMS, change the usermod to indicate that module
ISFPARMS is now owned by the SDSF JES2 feature FMID (JJE778S) and
not the base SDSF FMID (HQX7780). The correct SMP/E syntax is
++VER(Z038) FMID(JJE778S), not ++VER(Z038) FMID(HQX7780).</div></div></li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For details about invoking the conversion utility with the ISFACP
command, see >z/OS SDSF Operation and Customization</a>.</li>
<li>For information about ISFPARMS and the ISFPRM<var class="pv">xx</var> parmlib
member, see &quot;ISFPARMS format alternatives&quot; in  >z/OS SDSF Operation and Customization</a>.</li></ul>
<h2 id="wq529">SDSF actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes SDSF migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx901"></a><a id="idx902"></a><a id="idx903"></a><a id="idx904"></a><a id="idx905"></a><a id="idx906"></a>
<h3 id="wbmqsdsf">Update configuration for sysplex support</h3><a id="idx907"></a><a id="idx908"></a>
<p><strong>Description:</strong> When SDSF originally introduced
support for sysplex-wide device and resource panels in a JES2
environment, that support required WebSphere MQ,
SDSF servers and a server group defined in ISFPARMS. In recent releases,
SDSF enhancements have reduced the requirement for WebSphere MQ and the server
group. Beginning with z/OS V1R13,
SDSF completely eliminates the need for WebSphere MQ and the server group when all systems
are at the z/OS V1R13 level.</p>
<p>The following panels are made sysplex-wide by default: LI
(lines), NO (nodes), PUN (punches), RDR (readers) and SO (spool offloaders).</p>
<p>The following panels now use cross system coupling facility (XCF)
support to provide sysplex-wide data: CK (checks), ENC (enclaves),
PS (processes) and RM (JES2 resources). Using XCF for the sysplex-wide
data is preferable because XCF is always present and no configuration
is required.</p>
<p>If you have configured SDSF&rsquo;s sysplex support in previous
releases, you may now have obsolete WebSphere MQ configuration and server group definitions
in ISFPARMS.</p>
<p> For the CK, ENC, PS and RM panels, you may need to perform some
configuration to ensure that all of the systems are included in sysplex-wide
panels.</p>
<table id="wq530" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If all of the systems in the
sysplex are at the z/OS V1R13
level:</p>
<ul>
<li>Consider removing obsolete definitions:
<ul>
<li>Server group statements (SERVERGROUP, SERVER and COMM) in ISFPARMS.</li>
<li>WebSphere MQ configuration
and related SAF profiles, including queues that you defined for SDSF
and SAF profiles that protect the queues used by SDSF.</li></ul></li>
<li>Ensure that the names of the SDSF servers are the same on all
systems. By default, SDSF uses the SDSF server name for the XCF application
server name to obtain sysplex-wide data for the CK, ENC, PS
and RM panels. If the names of the servers are not the same on all
systems, you must specify the suffix of an XCF server name with the
CONNECT statement in ISFPARMS.</li></ul>
<p>If the sysplex includes systems at the z/OS V1R13 level, and others at a lower level, and
you want to include the lower level systems on the CK, ENC, PS or
RM panels, you must set the communications mode to Z12. This causes
SDSF to obtain sysplex-wide data as in previous releases, using WebSphere MQ and the server
group. To set the communications mode:</p>
<ul>
<li>Users can issue this command: SET CMODE Z12.</li>
<li>System programmers can use this custom property in ISFPARMS: Comm.Release.Mode.
You set a custom property with the PROPLIST and PROPERTY statements in
ISFPRM<var class="pv">xx </var> parmlib member.</li></ul>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about the <span class="pk">SET CMODE</span> command, refer
to the online help. For more information about ISFPRM<var class="pv">xx</var>, WebSphere MQ configuration
and security and the requirements for sysplex-wide panels when
the sysplex has mixed levels of z/OS and
JES2, refer to >z/OS SDSF Operation and Customization</a>.</li>
<li>For information about ISFPARMS and the ISFPRM<var class="pv">xx</var> parmlib
member, see &quot;ISFPARMS format alternatives&quot; in  >z/OS SDSF Operation and Customization</a>.</li></ul>
<h3 id="operlgcol">Review colors on the OPERLOG panel</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, messages are displayed on the OPERLOG
panel with the color that was assigned to them when they were issued.
Users can customize colors or disable the use of color with the SET
SCREEN command.<a id="idx909"></a></p>
<table id="wq531" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to disable color on the OPERLOG
panel.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To disable color on the OPERLOG
panel, use the <span class="pk">SET SCREEN</span> command.</p>
<p><strong>Reference information:</strong> For more information
on the <span class="pk">SET SCREEN</span> command, refer to the online help.</p>
<h3 id="pnchrdr">Set the format of device names on the Punch and Reader panels</h3>
<p><strong>Description:</strong> Starting with z/OS V1R13, SDSF shows device names on the Punch
(PUN) and Reader (RDR) panels in a longer format, with dots between
subtypes. This could affect batch programs or REXX execs that process
the device names. The system programmer can use a custom property
to retain the shorter format that was used in previous releases.<a id="idx910"></a><a id="idx911"></a><a id="idx912"></a><a id="idx913"></a></p>
<table id="wq532" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want device names on the PUN and
RDR panels to be displayed in the shorter format, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> In ISFPRM<var class="pv">xx</var>,
set custom property Panel.PUN.DevNameAlwaysShort and Panel.RDR.DevNameAlwaysShort
to TRUE, to use the short form of devices names on the PUN and RDR
panels.</p>
<p><strong>Reference information:</strong> For details about
setting the custom property in ISFPRM<var class="pv">xx</var>, see the
discussion of the PROPLIST nad PROPERTY statements, in >z/OS SDSF Operation and Customization</a>.</p>
<h3 id="definit">Set a default for the Initiators panel</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, SDSF shows WLM-managed initiators
as well as JES-managed initiators on the Initiators (INIT)
panel. This may result in a significantly greater number of rows than
were previously shown. New parameters, JES | WLM | ALL (ALL is the
default), on the INIT command allow users to specify which initiators
should be displayed. However, system programmers might want to set
a custom property so that only JES-managed initiators are shown
by default.</p>
<p><a id="idx914"></a><a id="idx915"></a><a id="idx916"></a><a id="idx917"></a><a id="idx918"></a></p>
<table id="wq533" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have WLM-managed initiators but
want only JES-managed initiators to be displayed on the INIT panel,
by default, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To set JES-managed
initiators as the default for the INIT panel, set custom property <span>Command.INIT.DefaultJESManage</span> to TRUE in ISFPRM<var class="pv">xx</var>.</p>
<p><strong>Reference information:</strong> For details about
setting the custom property in ISFPRM<var class="pv">xx</var>, see the discussion
of the PROPLIST and PROPERTY statements in >z/OS SDSF Operation and Customization</a>.</p>
<h3 id="prntpnl">Set the format of device names on the Printers panel</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, SDSF shows device names on the Printers
(PR) panel in a longer format, with dots between subtypes. This could
affect batch programs or REXX execs that process the device names.
The system programmer can use a custom property to retain the shorter
format that was used in previous releases.</p>
<p><a id="idx919"></a><a id="idx920"></a><a id="idx921"></a></p>
<table id="wq534" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want device names on the PR panel
to be displayed in the shorter format, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To use the short form of device
names on the PR panel, set custom property Panel.PR.DevNameAlwaysShort
to TRUE in ISFPRM<var class="pv">xx</var>.</p>
<p><strong>Reference information:</strong> For details about
setting the custom property in ISFPRM<var class="pv">xx</var>, see the discussion
of the PROPLIST and PROPERTY statements in >z/OS SDSF Operation and Customization</a>.</p>
<h3 id="msg770w">Update batch programs or REXX execs for changes to message
ISF770W</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, the text of message ISF770W has changed.
This might affect batch programs or REXX execs that depend on the
message text. The message is issued when the number of requests
(system commands) exceeds a limit set by a REXX special variable. </p>
<p>The text of the message changed from:</p>
<div class="lines">SYSTEM COMMAND LIMIT <em>limit</em> FROM VARIABLE <em>name</em> REACHED.<br />
to<br />
REQUEST LIMIT <em>limit</em> FROM VARIABLE <em>name</em> REACHED.&nbsp;&nbsp;<br />
</div>
<p><a id="idx922"></a><a id="idx923"></a></p>
<table id="wq535" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have batch programs or REXX execs
that depend on the text of message ISF770W.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review batch programs or REXX
execs for dependence on the text of message <span>ISF770W</span>,
and make changes as necessary.</p>
<p><strong>Reference information:</strong> For details about
SDSF's batch and REXX support, see >z/OS SDSF Operation and Customization</a>.</p>
<h3 id="operlog">Set the view of the OPERLOG</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, SDSF sets the view to include only active
log data when displaying the OPERLOG. Before z/OS V1R12, SDSF included both active and inactive
log data. Inactive log data is data for which there has been a delete
request but which is still in the log stream. If you have SDSF batch
programs or local procedures that depend on the presence of inactive
log data on SDSF's OPERLOG panel, you might need to update them.</p>
<p><a id="idx924"></a><a id="idx925"></a></p>
<table id="wq536" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have batch programs or local procedures
that depend on the presence of inactive log data on SDSF's OPERLOG
panel.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Review batch programs or local
procedures for a dependence on the presence of inactive log data on
the OPERLOG panel, and make changes as necessary. Alternatively, you
can use the PROPLIST and PROPERTY statements in ISFPRM<var class="pv">xx</var> to
set custom property Log.Operlog.ViewAll to TRUE, to cause the OPERLOG
panel to continue to include inactive log data.</p>
<p><strong>Reference information:</strong> For information about
the OPERLOG panel, see SDSF's online help. For details about SDSF's
batch support and custom properties in ISFPRM<var class="pv">xx</var>, see >z/OS SDSF Operation and Customization</a>.
For details about active and inactive log data, see >z/OS MVS Programming: Assembler Services Guide</a>.</p>
<h1 id="aq1secs">Security Server migration actions</h1>
<p>This topic describes migration actions for optional feature Security
Server.</p><a id="idx926"></a>
<h2 id="wq537">Security Server actions to perform before installing z/OS V1R13</h2>
<p>This topic describes Security Server migration actions that you
can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are made.<a id="idx927"></a><a id="idx928"></a><a id="idx929"></a><a id="idx930"></a><a id="idx931"></a></p>
<h3 id="distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h3>
<p><strong>Description:</strong> RACF provides
distributed identity filters in support of z/OS identity propagation. Before z/OS V1R13, RACF removed
leading and trailing blank characters before storing the user name
value of a distributed identity filter when you specified the user
name as an X.500 distinguished name (DN). Starting in z/OS V1R13, RACF normalizes the user name before storing it
in the RACF database. The normalization
process includes removing leading and trailing blank and null characters
from each relative distinguished name (RDN&reg;)
of the DN.</p>
<p><a id="idx932"></a><a id="idx933"></a><a id="idx934"></a></p>
<table id="wq538" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13,
and rolled back to z/OS V1R12
and z/OS V1R11 by APARs OA34259
and OA34258.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11 without the
PTFs for APARs OA34259 and OA34258 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>
<ul>
<li>Before installing z/OS V1R13
for determining if your installation has already defined any distributed
identity filters. Go to <a href="#befinst">Before installing z/OS V1R13</a> in this migration action.</li>
<li>Before the first IPL of z/OS V1R13
for customizing and executing the sample REXX exec IRR34258. Go to <a href="#befipl">Before the first IPL of z/OS V1R13</a> in this migration action.</li>
<li>After the first IPL of z/OS V1R13
for redefining a filter for an X.500 user identity. Go to <a href="#aftipl">After the first IPL of z/OS V1R13</a> in this migration action.</li></ul></td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation specified an X.500
DN as the user name of a distributed identity filter on a z/OS V1R12 or z/OS V1R11 system without the normalization function
provided with APARs OA34259 and OA34258.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>If your installation specified an X.500 DN as
the user name of a distributed identity filter on a z/OS V1R12 or z/OS V1R11
system without the normalization function provided with APARs OA34259
and OA34258, the filter might not function properly in z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<h4 id="wq539">Steps to take:</h4>
<h5 id="befinst">Before installing z/OS V1R13</h5>
<p> The following steps can be performed by the RACF security administrator or a RACF user with the SPECIAL attribute.</p>
<ol type="1">
<li>Determine whether your installation has already defined any distributed
identity filters. To do this, issue the following RACF command to search for profiles in the IDIDMAP
class. For details about the SEARCH command, see >z/OS Security Server RACF Command Language Reference</a>.
<pre class="xmp"><code>SEARCH CLASS(IDIDMAP)</code></pre>
<p>If
there are no profiles in the IDIDMAP class, your installation is unaffected
by this change. Skip to step <a href="#x500anext">7</a>.
No further migration actions for this change are required.</p></li>
<li>If you find profiles in the IDIDMAP class, discontinue defining
distributed identity filters until after the first IPL of z/OS V1R13.</li>
<li>Execute the RACF database
unload utility (IRRDBU00) to create a sequential file from a RACF database. For details about
running IRRDBU00, see >z/OS Security Server RACF Security Administrator&rsquo;s Guide</a>. 
<p>Save
the output dataset. You will use it for the steps in <a href="#befipl">Before the first IPL of z/OS V1R13</a>.</p></li>
<li>Determine whether the RACGLIST function is in effect for the IDIDMAP
class. To do this, issue the following command and review the output
listing for the status of the RACGLIST function.
<pre class="xmp"><code>SETROPTS LIST</code></pre>
<p>If
RACGLIST is not active, skip to step <a href="#x500anext">7</a>.</p></li>
<li>If RACGLIST is active, issue the following command:
<pre class="xmp"><code>SEARCH CLASS(RACGLIST)</code></pre>
<p>Review
the output for RACGLIST profile names prefixed by the class name <samp class="xph">IDIDMAP</samp>,
such as the following:</p>
<pre class="xmp"><code>IDIDMAP
IDIDMAP_00001
IDIDMAP_00002
...
IDIDMAP_0000<em>n</em></code></pre>
<p>If you find no RACGLIST
profiles like these, skip to step <a href="#x500anext">7</a>.</p></li>
<li id="x500aracg">If you find RACGLIST profiles names prefixed by
the class name <samp class="xph">IDIDMAP</samp>, disable the RACGLIST function of
the IDIDMAP class. To do this, issue the following RACF command:
<pre class="xmp"><code>RDELETE RACGLIST IDIDMAP</code></pre>
<p>You
can re-enable the RACGLIST function in the steps in <a href="#aftipl">After the first IPL of z/OS V1R13</a>.</p></li>
<li id="x500anext">Notify the programmer to install z/OS V1R13.</li></ol>
<h5 id="befipl">Before the first IPL of z/OS V1R13</h5>
<p>Perform the following steps <span class="bold-italic">only after</span> you
complete the steps in <a href="#befinst">Before installing z/OS V1R13</a>.</p>
<ol type="1">
<li>Customize the sample REXX exec IRR34258 (shipped in the IRR34258
member of SYS1.SAMPLIB) by specifying the name of the input data set
and the name and size of the output data set. 
<p>The IRR34258 program
reads the IRRDBU00 output data set (created in the steps in <a href="#befinst">Before installing z/OS V1R13</a>) and locates any IDIDMAP profiles that are affected
by this change.</p></li>
<li>Execute IRR34258 and review the output for the list of affected
IDIDMAP profiles.</li>
<li>Plan to complete the following actions <em>after</em> the
first IPL of z/OS V1R13.
<ul>
<li>If the output of IRR34258 identifies any affected IDIDMAP profiles,
plan to redefine the filters associated with each one.
<p>The IRR34258
output lists the USERDIDFILTER user name, REGISTRY name, RACF user ID, and label associated
with each filter to be redefined.</p></li>
<li>Ensure that no CICS, DB2, WebSphere DataPower,
or other application that exploits the z/OS identity
propagation APIs is restarted after the first IPL of z/OS V1R13 until all the steps required for this
change are completed.</li></ul></li>
<li>Proceed to IPL z/OS V1R13
for the first time.</li></ol>
<h5 id="aftipl">After the first IPL of z/OS V1R13</h5>
<p> Perform the following steps <span class="bold-italic">only after</span> you
complete the steps in <a href="#befipl">Before the first IPL of z/OS V1R13</a>.</p>
<ol type="1">
<li>Ensure that no CICS, DB2, WebSphere DataPower,
or other application that exploits the z/OS identity
propagation APIs is restarted after the first IPL of z/OS V1R13 until these steps are completed.</li>
<li>If the output from the sample REXX exec IRR34258 identified any
affected IDIDMAP profiles, use the RACF RACMAP
command to define a new distributed identity filter for each affected
IDIDMAP profile.
<p>When you define a new filter: </p>
<ul>
<li>Be sure to issue the RACMAP command from the V1R13 system, or
from a V1R11 or V1R12 system with the PTFs for APARs OA34258 and OA34259
applied.</li>
<li>Follow the steps in &quot;<a href="../com.ibm.zos.r13.icha700/sagx500.htm">Defining a filter for an X.500 user identity</a>&quot; in ></a>.</li>
<li>Use the same USERDIDFILTER user name, REGISTRY name, and RACF user ID that was associated
with the old filter, as listed in the IRR34258 output.</li>
<li>Do not use the label name that was associated with the old filter.
You must specify a new label name.</li></ul></li>
<li>Install z/OS V1R13, or
the PTFs for APARs OA34258 and OA34259, on each member system in the
sysplex using a rolling IPL (one system at a time).</li>
<li>Delete the affected IDIDMAP profiles that were identified in the
output of the IRR34258 program. To delete the profiles, issue the
RACMAP DELMAP command specifying the label names listed in the IRR34258
output.</li>
<li>If you disabled the RACGLIST function for the IDIDMAP class in
step <a href="#x500aracg">6</a> in <a href="#befinst">Before installing z/OS V1R13</a>, enable it
again by issuing the following RACF command:
<pre class="xmp"><code>RDEFINE RACGLIST IDIDMAP</code></pre></li>
<li>Restart any CICS, DB2, WebSphere DataPower,
or other application that exploits the z/OS identity
propagation APIs, as needed.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>Documentation in the PTFs for APARs OA34258 and OA34259.</li>
<li>For information about how to use a distributed identity filter
to map distributed identities to a RACF user
ID, see &quot;<a href="../com.ibm.zos.r13.icha700/sagdid.htm">Distributed identity
filters</a>&quot; in ></a>.</li>
<li>For details about the normalization rules, see the USERDIDFILTER
operand of the RACMAP command in >z/OS Security Server RACF Command Language Reference</a>.</li></ul>
<h2 id="wq543">Security Server actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes Security Server migration actions that you
can perform after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p><a id="idx935"></a><a id="idx936"></a><a id="idx937"></a><a id="idx938"></a><a id="idx939"></a><a id="idx940"></a><a id="idx941"></a>
<h3 id="aq3cdcn">Check for duplicate class names</h3>
<p><strong>Description:</strong> When new classes are
shipped with RACF, you should
verify that any installation-defined class names that have been added
to the class descriptor table (CDT) do not conflict with the new classes. <a id="idx942"></a><a id="idx943"></a><a id="idx944"></a><a id="idx945"></a><a id="idx946"></a>For a list of new classes shipped with RACF, see >z/OS Summary of Message and Interface Changes</a>.</p>
<table id="wq544" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have user-defined classes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Verify that any installation-defined
class names that have been added to the class descriptor table (CDT)
do not conflict with the new classes. </p>
<ul>
<li>If you have duplicate class names, RACF issues
the following message and enters failsoft mode: 
<pre class="xmp"><code>ICH564A RACF DETECTED AN ERROR IN THE INSTALLATION CLASS DESCRIPTOR TABLE,
ENTRY <var class="pv">class_name</var>, ERROR CODE 7</code></pre></li>
<li>If a conflict in class names occurs, resolve it as follows:
<ol type="1">
<li>Delete the profiles in the installation-defined class with the
conflicting name.</li>
<li>Delete the CDT entry for the class.</li>
<li>Add a CDT entry with a different name.</li>
<li>Redefine the profiles.</li></ol></li></ul>
<p><strong>Reference information:</strong> See >z/OS Security Server RACF System Programmer&rsquo;s Guide</a>.</p><a id="idx947"></a><a id="idx948"></a><a id="idx949"></a>
<h3 id="wq546">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h3>
<p>Go to <a href="#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h2 id="wq547">Security Server actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes Security Server migration actions that you
can perform only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx950"></a><a id="idx951"></a><a id="idx952"></a><a id="idx953"></a><a id="idx954"></a><a id="idx955"></a><a id="idx956"></a>
<h3 id="aq3dbte">Update database templates</h3>
<p><strong>Description:</strong> To ensure that
the RACF utilities function
properly, use the IRRMIN00 utility to update the primary and backup RACF databases with the database
templates for the current release level.<a id="idx957"></a><a id="idx958"></a><a id="idx959"></a></p>
<table id="wq548" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> To install the database template
updates, run the IRRMIN00 utility with PARM=UPDATE.</p>
<div>
<div class="notetitle" id="wq549">Note:</div>
<div class="notebody">If IRRMIN00 produces a return code of 4 and message <samp class="xph">IRR8025
PARM=UPDATE specified, but template update not required</samp>, you
do not necessarily have a problem. Check that your JCL points to the
new level of IRRMIN00. If it does, ignore the return code and warning
message. A PTF might have already brought your templates up to the
current level for the new release. If your JCL accidentally points
to an old copy of IRRMIN00, correct the JCL and run IRRMIN00 again.</div></div>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS Program Directory</a></li>
<li><cite>ServerPac: Installing Your Order</cite></li>
<li>>z/OS Security Server RACF System Programmer&rsquo;s Guide</a></li></ul><a id="idx960"></a><a id="idx961"></a><a id="idx962"></a>
<h3 id="wq550">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h3>
<p>Go to <a href="#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h3 id="digicert">Use new RACDCERT GENCERT and REKEY defaults for digital certificates</h3><a id="idx963"></a><a id="idx964"></a><a id="idx965"></a>
<p><strong>Description:</strong> Before z/OS V1R12, when RACDCERT GENCERT was issued, the
hashing algorithm signed the certificate by an RSA key and was always
SHA1. Starting in z/OS V1R12,
the hashing algorithm relies on the size of the RSA signing key.</p>
<p>Also, before z/OS V1R12,
when RACDCERT REKEY was issued, the default key type was always software
key, if ICSF or PCICC was not specified, and the default key size
was always 1024 bits if SIZE was not specified. Starting in z/OS V1R12, instead of using these
hard coded values, the key type and the key size of the original certificate,
which REKEY is based on, is used.</p>
<table id="wq551" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if RACDCERT GENCERT or REKEY command is
issued.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<p>If issuing RACDCERT GENCERT, be aware the default hashing algorithm
in signing is changed. </p>
<ul>
<li>The hashing algorithm now relies on the size of the RSA signing
key. If key size is:
<ul>
<li>less than 2048 bits, SHA1 is used</li>
<li>greater than or equal to 2048 bits, SHA256 is used</li></ul>Also, if you need a SHA1 hashing algorithm, use a RSA signing
key less than 2048 bits.</li></ul>
<p>If issuing RACDCERT REKEY, be aware the defaults for key size and
key type are changed.</p>
<ul>
<li>The key type and the key size of the original certificate, which
REKEY is based on, are now used.</li>
<li>You can no longer REKEY to a software key, if the original key
is a hardware key.
<p>If you must downgrade a hardware key to a software
key, use GENCERT and specify the same certificate information as in
the original certificate in the input but without specifying ICSF
or PCICC. ICSF or PCICC are the keywords in the GENCERT command for
hardware key.</p></li></ul>
<div>
<div class="notetitle" id="wq552">Note:</div>
<div class="notebody">RACDCERT REKEY cannot be used to create a software
key if the original key is a hardware key.</div></div>
<p><strong>Reference information:</strong> See the >z/OS Security Server RACF Command Language Reference</a> for
more information about the RACDCERT GENCERT and REKEY commands.</p>
<h1 id="ar1smpe">SMP/E migration actions</h1>
<p>This topic describes migration actions for base element SMP/E.</p><a id="idx966"></a>
<div>
<div class="notetitle" id="wq553">Note:</div>
<div class="notebody">SMP/E is a driving system element and, as such, is
fully usable from your driving system by accessing the installed SMP/E
target libraries before an IPL. For this reason, SMP/E migration actions
are presented in two categories rather than the three categories normally
used for migration information. The two categories are:
<ul>
<li>SMP/E actions to perform after installing SMP/E V3R6 (z/OS V1R13 SMP/E) but before starting
to use it.</li>
<li>SMP/E actions to perform after starting to use SMP/E V3R6 (z/OS V1R13 SMP/E).</li></ul></div></div>
<h2 id="wq554">SMP/E actions to perform after installing SMP/E V3R6 (z/OS V1R13 SMP/E) but before starting
to use it</h2>
<p>This topic describes SMP/E migration actions that you can perform
after installing SMP/E V3R6 (which is in V1R13), but before you start
to use it.</p><a id="idx967"></a><a id="idx968"></a>
<h3 id="smpecmd">Authorize use of SMP/E commands and services</h3>
<p><strong>Description:</strong> Beginning with SMP/E V3R5 (which
is in z/OS V1R10, z/OS V1R11, and z/OS V1R12), with the PTF for APAR IO11698 applied,
System Authorization Facility (SAF) checks are added to SMP/E. With
this change, only users who have sufficient access authority are able
to invoke SMP/E functions, including all SMP/E commands (for example,
RECEIVE, APPLY, LIST), the GIMZIP and GIMUNZIP service routines, and
the GIMIAP copy utility invocation program.</p>
<p>To ensure current users have the access authority to invoke SMP/E
functions, you must define appropriate SAF facility class profiles
in the active security manager and specify all user IDs that need
to use SMP/E functions in the access lists of these profiles. These
functions include: </p>
<ul>
<li>All SMP/E commands processed by program GIMSMP. For example, SET,
RECEIVE, APPLY, ACCEPT, UCLIN, LIST, REPORT, and so on.</li>
<li>The GIMZIP and GIMUNZIP service routines, used for packaging and
file extraction.</li>
<li>The GIMIAP copy utility invocation program used in jobs created
by the SMP/E GENERATE command.</li></ul><a id="idx969"></a><a id="idx970"></a><a id="idx971"></a>
<table id="wq555" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>SMP/E.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>SMP/E V3R5 (z/OS V1R10, z/OS V1R11, and z/OS V1R12) with APAR IO11698.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>SMP/E V3R5 (which is in z/OS V1R10, z/OS V1R11,
and z/OS V1R12), without the
PTF for APAR IO11698 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before starting to use SMP/E V3R6 (which is
in z/OS V1R13).</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Authorize use of SMP/E commands
and services <strong>before</strong> you apply the PTF for APAR
IO11698.  For further information see:</p>
<ul>
<li> <a href="../com.ibm.zos.r13.gim3000p/authorizecommands.htm">Authorizing use of SMP/E commands and services</a> in >SMP/E User&rsquo;s Guide</a>.</li>
<li>INFO APAR II14489.</li>
<li>APAR IO12263</li></ul>
<p><strong>Reference information:</strong> For details about
authorizing use of SMP/E commands and services, see >SMP/E Messages, Codes, and Diagnosis</a> and >SMP/E User&rsquo;s Guide</a>.</p>
<h2 id="wq556">SMP/E actions to perform after starting to use SMP/E V3R6 (z/OS V1R13 SMP/E)</h2>
<p>None.</p>
<h1 id="tsoemig">TSO/E migration actions</h1>
<p>This topic describes migration actions for base element Time Sharing
Option/Extensions (TSO/E).</p><a id="idx972"></a>
<h2 id="wq557">TSO/E actions to perform before installing z/OS V1R13</h2>
<p>This topic describes TSO/E migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p>
<p>None.</p><a id="idx973"></a><a id="idx974"></a><a id="idx975"></a><a id="idx976"></a><a id="idx977"></a>
<h3 id="tsosynt">Do not rely on TSO/E to check the syntax of passwords</h3>
<p><strong>Description:</strong> <a id="idx978"></a>Starting
with z/OS V1R12, TSO/E LOGON
will no longer check syntax of eight character or less passwords before
passing them on to the security product for verification. Prior to
this change, TSO/E would only allow alphanumeric or national characters
(a-z, A-Z, 0-9, @, #, $) to be entered in an eight character or less
new or existing password on the TSO/E LOGON panel.  If any other characters
were entered, an error message would be displayed and the user would
be prompted again: </p>
<dl>
<dt class="bold">IKJ56464I</dt>
<dd>You have entered unacceptable characters in the highlighted
field(s)
</dd>
<dt class="bold">IKJ56465I</dt>
<dd>Press PF1 or PF13 for help
</dd>
</dl><p class="indatacontent">With this change, TSO/E will no longer limit the characters that
can be entered for a new or existing password on the TSO/E LOGON panel.
 If the security product limits the acceptable characters, then a
user will see the following error messages, instead:</p>
<dl>
<dt class="bold">IKJ56414I</dt>
<dd>NEW-PASSWORD IS INVALID FOR RACF
</dd>
<dt class="bold">IKJ56429A</dt>
<dd>REENTER -
</dd>
</dl><p class="indatacontent">Or, alternatively:</p>
<dl>
<dt class="bold">IKJ56421I</dt>
<dd>PASSWORD NOT AUTHORIZED FOR USERID
</dd>
<dt class="bold">IKJ56429A</dt>
<dd>REENTER -
</dd>
</dl><p class="indatacontent">Only the TSO/E LOGON panel is affected by this change.  Line
mode LOGON will still restrict user passwords to alphanumeric or national
characters (a-z, A-Z, 0-9, @, #, $) to be entered in an eight character
or less. Other applications such as JCL might still fail certain special
characters entered in eight character passwords.  In addition, the
unrelated MIXEDCASE setting for passwords in RACF will still control whether or not lowercase
letters are converted to uppercase during LOGON using the TSO/E LOGON
panel.  Similarly, password phrases with nine characters or more entered
during TSO/E LOGON are not affected by this change.</p>
<table id="wq558" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>TSO/E.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11
with PTF for APAR OA29028 applied.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without PTF for APAR OA29028 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid problems, for example,
if a user or application is relying on the existing behavior of the
LOGON panel.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong></p>
<ul>
<li>In a sysplex with multiple levels of z/OS or multiple security products, check if there
is a compatibility mode that can be used to ensure the security products
enforce the password syntax rules uniformly between the different
systems.</li>
<li>Note that systems prior to z/OS V1R12
will continue to enforce the previous syntax rules unless the PTF
for APAR OA29028 is applied.</li>
<li>Update automation or software that relies on message IKJ56464I
to indicate that invalid characters were entered for a new or existing
password.</li></ul>
<p><strong>Reference information:</strong> For additional information
about controlling user logons, see  >z/OS TSO/E Customization</a>.</p>
<h2 id="wq559">TSO/E actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes TSO/E migration actions that you can perform
after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.<a id="idx979"></a><a id="idx980"></a><a id="idx981"></a><a id="idx982"></a><a id="idx983"></a><a id="idx984"></a></p>
<p>None.</p>
<h2 id="wq560">TSO/E actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes TSO/E migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx985"></a><a id="idx986"></a><a id="idx987"></a><a id="idx988"></a><a id="idx989"></a><a id="idx990"></a>
<h3 id="tsosmsinfo">Specify the SMSINFO keyword on LISTDSI to retrieve detailed
PDSE information</h3>
<p><strong>Description:</strong> APAR OA35217 updated the LISTDSI
function for REXX and the LISTDSI statement for CLIST to avoid updating
the last referenced date for PDSE data sets unless the SMSINFO keyword
is specified.  However, the detailed information provided in the SYSDSSMS
variable to describe whether a PDSE is a LIBRARY, DATA_LIBRARY, or
PROGRAM_LIBRARY can only be retrieved by opening the data set and
updating the last referenced date.  This information was being retrieved
unconditionally for PDSEs, which caused the last referenced date to
be updated whenever LISTDSI was used to check a PDSE.  With this change,
the information will only be retrieved, and the last referenced date
will only be updated if the SMSINFO keyword is specified when LISTDSI
is invoked.<a id="idx991"></a></p>
<table id="wq561" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>TSO/E</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11,
V1R12, and V1R13 with the PTF for APAR OA35217 applied.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11,
V1R12, and V1R13 without the PTF for APAR OA35217 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R11, V1R12, and V1R13 with the PTF for APAR
OA35217 applied.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if REXX or CLIST applications expect to
see detailed PDSE information returned by the SYSDSSMS variable for
the LISTDSI function when the SMSINFO keyword is not specified.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> For updated REXX execs of
CLISTs that expect the SYSDSSMS variable set by LISTDSI to return
either 'LIBRARY', 'DATA_LIBRARY', or 'PROGRAM_LIBRARY' for PDSE data
sets but have not specified SMSINFO, add the SMSINFO keyword to the
invocation of the LISTDSI function or the REXX exec, or update the
CLIST so that the expected value of the SYSDSSMS variable is 'PDSE'
instead.</p>
<p><strong>Reference information:</strong> For additional information
about the REXX LISTDSI function, see <cite></cite>. For additional information about the
CLIST LISTDSI statement, see <cite></cite>.</p>
<h3 id="dsrecmd">Accommodate changes for data sets allocated by the RECEIVE
command</h3>
<p><strong>Description:</strong> New data set allocation during
RECEIVE command processing has changed as follows:</p>
<ul>
<li>Before z/OS V1R9, TSO/E
would allocate a data set during RECEIVE command processing without
using the AVGREC option. As a result, the ISPF data set information
panel would display the size of the data set in blocks, tracks or
cylinders.</li>
<li>In z/OS V1R10 and z/OS V1R11, without the PTF for
APAR OA27537 applied, TSO/E will allocate a data set during RECEIVE
command processing using the AVGREC option. As a result, the ISPF
data set information panel would display the size of the data set
in bytes.</li>
<li>In z/OS V1R11, with the
PTF for APAR OA27537 applied, the behavior is changed back to what
it was before z/OS V1R9.</li></ul><a id="idx992"></a>
<p>Regardless of the release, the following has been, and continues
to be, true: the LISTDSI function in REXX or CLIST returns the size
in blocks or tracks, and data sets that are preallocated (that is,
not allocated by RECEIVE command processing) are not affected by the
changes.</p>
<table id="wq562" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>TSO/E.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>z/OS V1R8 and earlier had
the original behavior.</li>
<li>z/OS V1R9, V1R10 and V1R11
without the PTF for APAR OA27537 applied have the new behavior.</li>
<li>z/OS V1R9, V1R10 and V1R11
with the PTF for APAR OA27537 applied return to the original behavior.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11
without the PTF for APAR OA27537.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if users expect to see data set allocation
information in bytes in ISPF for data sets allocated during TSO/E
RECEIVE processing.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Notify users that ISPF displays
the size of data sets in blocks or tracks, instead of bytes, if the
data sets are allocated by TSO/E RECEIVE command processing.</p>
<p><strong>Reference information:</strong> None.</p>
<h1 id="ac1ccpp">XL C/C++ migration actions</h1>
<p>This topic describes migration actions for optional feature C/C++
without Debug Tool.</p>
<div>
<div class="notetitle" id="wq563">Note:</div>
<div class="notebody">As of z/OS V1R7,
the C/C++ compiler has been rebranded to XL C/C++. However, the name
of the optional feature that contains the XL C/C++ compiler remains
C/C++ without Debug Tool.</div></div><a id="idx993"></a><a id="idx994"></a>
<h2 id="wq564">XL C/C++ actions to perform before installing z/OS V1R13</h2>
<p>This topic describes XL C/C++ migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to make these changes,
and the changes do not require the z/OS V1R13
level of code to run once they are made.</p><a id="idx995"></a><a id="idx996"></a><a id="idx997"></a><a id="idx998"></a>
<h3 id="revappl">Review the XL C/C++ Migration Guide for the Application Programmer</h3>
<p><strong>Description:</strong> The publication >z/OS XL C/C++ Compiler and Run-Time Migration Guide for the Application Programmer</a> is written for application programmers,
whereas this publication (<em>z/OS Migration</em>) is written for system programmers.
However, in some customer locations, job scope could overlap such
that system programmers might find information in the XL C/C++ publication
that is relevant to their responsibilities. For example, migration
information related to the c89 utility in the XL C/C++ publication
could be of interest. Therefore, you ought to review the XL C/C++
publication if you use XL C/C++.</p>
<table id="wq565" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>C/C++ without Debug Tool.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use XL C/C++.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Look through >z/OS XL C/C++ Compiler and Run-Time Migration Guide for the Application Programmer</a> for migration information that is relevant
to your installation.</p>
<p><strong>Reference information:</strong> >z/OS XL C/C++ Compiler and Run-Time Migration Guide for the Application Programmer</a></p>
<h2 id="wq566">XL C/C++ actions to perform before the first IPL of z/OS V1R13</h2>
<p>None.</p>
<h2 id="wq567">XL C/C++ actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes XL C/C++ migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx999"></a><a id="idx1000"></a><a id="idx1001"></a><a id="idx1002"></a><a id="idx1003"></a><a id="idx1004"></a>
<h3 id="ipaobno">Update IPA compiler option IPA(OBJECT)</h3>
<p><strong>Description:</strong> Starting with z/OS V1R12, the <em>XL C/C++</em> compiler
option IPA(OBJECT) matches the behavior of IPA on other platforms
and generates object code with additional optimization. The suboption
IPA(OBJONLY) is deprecated.<a id="idx1005"></a></p>
<table id="wq568" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>C/C++ without Debug Tool.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the suboption IPA(OBJONLY) is used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use the XL C/C++ IPA(OBJECT
| NOOBJECT) compiler options to perform IPA compile-time optimizations.</p>
<p><strong>Reference information:</strong> For details about
the changes to the IPA(OBJECT | NOOBJECT) compiler options, see >z/OS XL C/C++ Compiler and Run-Time Migration Guide for the Application Programmer</a>.</p>
<h1 id="as1unss">z/OS UNIX migration actions</h1>
<p>This topic describes migration actions for base element z/OS UNIX System
Services (z/OS UNIX).</p><a id="idx1006"></a>
<h2 id="wq569">z/OS UNIX actions to perform before installing z/OS V1R13</h2>
<p>This topic describes z/OS UNIX migration actions that you
can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are made.</p><a id="idx1007"></a><a id="idx1008"></a><a id="idx1009"></a><a id="idx1010"></a>
<h3 id="zmountusr">Update invocations of /usr/sbin/mount commands</h3>
<p><strong>Description:</strong> Before z/OS V1R13, when using the <span class="pk">/usr/sbin/mount</span> command
with the <span class="pk">-o</span> <var class="pv">fsoptions</var> option, that option
was ignored for zFS file systems if the <span class="pk">-t</span> option
was not used to specify the file system type. Starting with z/OS V1R13, the <span class="pk">-o</span> <var class="pv">fsoptions</var> option
is not ignored in that situation, which might cause the mount to (1)
fail or (2) proceed but with possible unintended results. <a id="idx1011"></a></p>
<table id="wq570" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because invocations of <span class="pk">/usr/sbin/mount</span> 
might fail , or if the mount does not fail, the results might be unpredictable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you have invocations of
the <span class="pk">/usr/sbin/mount</span> command that do not use the <span class="pk">-t</span> option
to specify the file system type but specifies zFS-specific
options using the <span class="pk">-o</span> <var class="pv">fsoptions</var> option, take
the following actions: </p>
<ol type="1">
<li>If you want to keep the <span class="pk">-o</span> <var class="pv">fsoptions</var> option,
determine the type of the file system and specify it, using the <span class="pk">-t</span> option.</li>
<li>If the file system is zFS, verify that the options string that
was specified in <span class="pk">-o</span> <var class="pv">fsoptions</var> is valid.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>See the <a href="../com.ibm.zos.r13.bpxa500/mount.htm">mount command </a> in >z/OS UNIX System Services Command Reference</a>.</li>
<li>See the section on <a href="../com.ibm.zos.r13.bpxb200/zmount.htm">mounting
considerations for zFS</a> in >z/OS UNIX System Services Planning</a>.</li></ul>
<h3 id="binunmnt">Update invocations of /usr/sbin/unmount commands</h3>
<p><strong>Description:</strong> Before z/OS V1R13, if a path name was specified when using
the <span class="pk">/usr/sbin/unmount</span> command to unmount a file system, the
path name could be (1) any file or directory in the file system or
(2) the mount point of the file system. Starting in z/OS V1R13, when the <span class="pk">/usr/sbin/unmount</span> command
is issued, only the mount point can be specified for the path name.</p>
<p>Unmounting based on using any file or directory in a file
system can sometimes cause the wrong file system from being unmounted.
There can be instances, for example, where the file system has already
been unmounted and a subsequent unmount on the same path name would
result in accidentally unmounting the wrong file system. <a id="idx1012"></a></p>
<table id="wq572" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because invocations of <span class="pk">/usr/sbin/unmount</span> 
might fail if the path name is not the name of the mount point.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If the path name is not the name of the mount
point, the following message is displayed: FOMF0512I Path is not a
mountpoint: <var class="pv">path-name</var>.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you have invocations of
the <span class="pk">/usr/sbin/unmount</span> command that do not specify a mount
point on the <var class="pv">name...</var> parameter, follow these steps:</p>
<ol type="1">
<li>Look for instances where the specified path names in <span class="pk">/usr/sbin/unmount</span> invocations
are files or directories.</li>
<li>Select one of the following actions:
<ul>
<li>Use the <strong> -m</strong> option in <span class="pk">/usr/sbin/unmount</span> command
if you have confirmed that something other than mount point needs
to be specified.  Note the file system that contains the file or the
directory will be unmounted.</li>
<li>Change the invocation so that only mount points are specified
for the path name.</li></ul></li></ol>
<p><strong>Reference information:</strong> Refer to the <span class="pk">unmount</span> command
in >z/OS UNIX System Services Command Reference</a> for
further information.</p>
<h3 id="bpx1bpx4">Review programs that invoke the BPX1EXM/BPX4EXM callable service</h3>
<p><strong>Description:</strong> Before z/OS V1R12 (and without the PTFs
for APAR OA30897 installed on z/OS V1R11, z/OS V1R10, and z/OS V1R9), an unauthorized caller could pass a
parameter greater than 100 characters on the BPX1EXM/BPX4EXM (execmvs)
syscall. Beginning with z/OS V1R12
(and with the PTFs for APAR OA30897 installed to z/OS V1R11, z/OS V1R10,
and z/OS V1R9), EC6 abends
with reason code 0B26C048 will occur if: (1) the caller is not authorized,
(2) the parameter is greater than 100 characters, and (3) the program
would be executed in an authorized state.</p>
<p>Message BPXP027I goes to the system hardcopy log. See
message BPXP027I for the program name and the argument length:</p>
<pre class="xmp"><code>BPXP027I JOBNAME <var class="pv">jobname</var>, ATTEMPTED TO ISSUE AN EXEC OF THE APF AUTHORIZED MVS PROGRAM, <var class="pv">pgmname</var>, WITH A PARM LENGTH OF <var class="pv">xxx</var></code></pre><p class="indatacontent"> <a id="idx1013"></a></p>
<table id="wq574" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12,
and z/OS V1R11, z/OS V1R10 and z/OS V1R9 with the PTFs for APAR OA30897 installed.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11,
without the PTF for APAR OA30897 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have a program that fits the criteria
in the Description section above.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ul>
<li>Review BPX1EXM/BPX4EXM calls from unauthorized callers that might
call an APF-authorized program with an argument parameter greater
than 100 characters.
<ul>
<li>If the program can handle an argument greater than 100 characters,
define a profile for the FACILITY class resource name BPX.EXECMVSAPF.<var class="pv">program_name</var>.
<div>
<div class="notetitle" id="wq575">Note:</div>
<div class="notebody">Individual users do not need to be given access
to the profile; the profile just needs to be defined. Also, the <var class="pv">program_name</var> defines
the target APF-authorized program. .</div></div></li>
<li>If the program cannot handle an argument greater than 100 characters,
change the BPX1EXM/BPX4EXM calls to pass an argument that is 100 characters
or less.</li></ul></li></ul>
<p><strong>Reference information:</strong> For more information
about BPX.EXECMVSAPF.<var class="pv">program_name</var>, see >z/OS UNIX System Services Planning</a>.</p>
<h3 id="shelluti">Accommodate the new Shell and Utilities version of the tsocmd
command</h3>
<p><strong>Description:</strong>  Before z/OS V1R11, the <span class="pk">tsocmd</span> command was obtained
from the Tools and Toys section of the z/OS UNIX web site. Starting with z/OS V1R12, Shell and Utilities
support of the <span class="pk">tsocmd</span> command has been added. The supported
version differs from the Tools and Toys version in a number of ways.
For example:</p>
<ul>
<li>Exit values are consistently sent if the issued TSO/E command
fails.</li>
<li>The tsoin and tsoout environment variables are not supported.
Instead, stdin and stdout are supported, as is done for most other
Shell and Utilities commands.</li>
<li>The TSOPROFILE environment variable is supported.</li>
<li>The READY and END lines are no longer part of the tsocmd
command output.</li></ul><a id="idx1014"></a>
<table id="wq576" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use the Tools and Toys
version of the <span class="pk">tsocmd</span> command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> Look for current use of the
Tools and Toys version of <span class="pk">tsocmd</span>. If there is no current
use of the Tools and Toys version of <span class="pk">tsocmd</span>, then no actions
or changes are required.</p>
<p></p>
<p>If there is current use of the Tools and Toys version of <span class="pk">tsocmd</span>,
determine if the command is located in <samp class="xph">/bin</samp> or in another
directory. Also, determine if you want to preserve the Tools and Toys
version in addition to the officially shipped version.</p>
<ol type="1">
<li>If you want to preserve the Tools and Toys version, ensure the
Tools and Toys version of <span class="pk">tsocmd</span> is not located in <samp class="xph">/bin</samp> prior
to the installation of z/OS V1R13.</li>
<li id="tsostep">If you do not want to preserve the Tools and Toys
version, and it is located in <samp class="xph">/bin</samp>, then the installation
of z/OS V1R13 will automatically
replace the Tools and Toys version with the new officially supported
version.  If the Tools and Toys version is not located in <samp class="xph">/bin</samp>,
remove it from its current location.  In either case, you will also
need to remove the Tools and Toys <span class="pk">tsocmd</span> load module from
the authorized load library (either prefix.TSOCMD.LOADLIB or SYS1.LINKLIB)
as described in the <span class="pk">tsocmd</span> Tools and Toys README documentation
available at ftp://ftp.software.ibm.com/s390/zos/tools/tsocmd/tsocmd.readme.txt.</li></ol>
<div>
<div class="notetitle" id="wq578">Note:</div>
<div class="notebody">A new version of <span class="pk">tsocmd</span> that matches the
version shipped with z/OS V1R12
is available at the Tools and Toys web site.  If you have multiple
systems at different releases and you want to have the same version
of the tool on all releases, or if you want to try out the new command
prior to z/OS V1R12, you can
download the new version to the earlier systems and replace the previous
Tools and Toys version of <span class="pk">tsocmd</span> if appropriate.  If this
action is taken, you will need to clean up the authorized load library
as described in Step <a href="#tsostep">2</a> prior to downloading the
new tool.</div></div>
<p><strong>Reference information:</strong> For information about
the <span class="pk">tsocmd</span> command, see >z/OS UNIX System Services Command Reference</a>.</p>
<h3 id="maxsock">Remove MAXSOCKETS values from AF_UNIX in the BPXPRMxx parmlib
member</h3>
<p><strong>Description:</strong> Before z/OS V1R12, a value had to be specified for the
MAXSOCKETS keyword in the NETWORK statement for AF_UNIX in the BPXPRM<var class="pv">xx</var> parmlib
member of SYS1.PARMLIB if the maximum number of AF_UNIX sockets for
the system needed to be greater than the default of 100. As of z/OS V1R12, the value does not
need to be specified because a maximum value of 10,000 has been set
for MAXSOCKETS for AF_UNIX.  The MAXSOCKETS keyword is still allowed
on the NETWORK statement for AF_UNIX, but will be ignored on a z/OS V1R12 system. <a id="idx1015"></a><a id="idx1016"></a></p>
<table id="wq579" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid confusion if users
do not know that a value does not need to be specified for the MAXSOCKETS
keyword on the NETWORK statement for AF_UNIX for z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>If you share your BPXPRM<var class="pv">xx</var> parmlib
member with lower level systems, only remove your MAXSOCKETS statement
from your AF_UNIX domain if you will accept the default MAXSOCKETS
value for AF_UNIX for those lower level systems.  (The default on z/OS V1R11 for MAXSOCKETS in the
AF_UNIX domain is 100.)  Otherwise, remove the MAXSOCKETS statement
from the AF_UNIX domain when all systems that share the BPXPRM<var class="pv">xx</var> parmlib
member are at z/OS V1R12 or
later.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Remove any MAXSOCKETS statement
from NETWORK statements for DOMAINNAME(AF_UNIX). In a configuration
with a shared BPXPRM<var class="pv">xx</var> parmlib, MAXSOCKETS should only be
removed when all systems are at z/OS V1R12 <span>or later</span>.</p>
<p><strong>Reference information:</strong> For information about
the BPXPRM<var class="pv">xx</var> member, see >z/OS UNIX System Services Planning</a> and >z/OS MVS Initialization and Tuning Reference</a>.</p>
<h3 id="conscal">Discontinue use of z/OS UNIX System Services Connection
Scaling</h3>
<p><strong>Description:</strong>  Starting with z/OS V1R13, support of z/OS UNIX System
Services Connection Scaling, specifically the Connection Manager and
Process Manager components, is discontinued. FMID HCMG110, JCMG1J0,
HPMG110, and JPMG1J0 are removed from z/OS V1R13.<a id="idx1017"></a><a id="idx1018"></a><a id="idx1019"></a></p>
<table id="wq580" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13
(previewed in z/OS V1R12 Software
Announcement 210-235, dated July 22, 2010).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because it will become a
requirement in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> Discontinue use of z/OS UNIX System
Services Connection Scaling. z/OS UNIX System Services Connection
Scaling consists of these FMIDs:  HCMG110 (Connection Manager), JCMG1J0
(Connection Manager Japanese), HPMG110 (Process Manager), and JPMG1J0
(Process Manager Japanese).</p>
<p><strong>Reference information:</strong> None</p>
<h3 id="hfs2zfs">Migrate from HFS file systems to zFS file systems</h3>
<p><strong>Description:</strong> Before z/OS V1R7, the HFS file system was the primary hierarchical
file system. As of z/OS V1R7,
you can use any combination of HFS and zFS file systems. Because zFS
has higher performance characteristics than HFS and is the strategic
file system, you should migrate your HFS file systems to zFS.<a id="idx1020"></a><a id="idx1021"></a></p>
<p>The HFS and zFS file system types in mount statements and command
operands are now generic file system types that can mean either HFS
or zFS. Based on the data set type, the system will determine which
is appropriate. But note that you must still specify a type (HFS or
zFS and it cannot be defaulted), and if the type you specify is not
correct for the file system being mounted, any associated parameter
string setting in the mount statement or command is ignored, even
though the system sets the type correctly and processes the mount.</p>
<table id="wq581" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>zFS became the strategic file system in z/OS V1R7.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the action is planned
to become a requirement in a future release. zFS is the strategic
file system for z/OS UNIX and continues to be enhanced
to provide superior performance, reliability, and data integrity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>Understand the zFS recommendations and limits.
For more information, see <a href="../com.ibm.zos.r13.ioea700/mimafs.htm">Minimum
and maximum file system sizes</a> in >z/OS Distributed File Service zSeries File System Administration</a></td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check USS_HFS_DETECTED to verify all file
systems mounted. This check issues exception message BPXH068E if any
HFS file systems are found. <span>To use this check on z/OS V1R11, you must first install
the PTF for APAR OA29947.</span></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<ol type="1">
<li>Before beginning the migration, do the following:
<ul>
<li>Establish backout procedures.</li>
<li>Decide on naming conventions.</li>
<li>Decide on unavailability.</li>
<li>Understand any cloning or deployment changes required by zFS systems
being linear data sets. Considerations would include any copy utility
invocations, BPXPRMxx specifications for symbolics, and placement
of zFS file systems on system volumes.</li></ul></li>
<li>Perform the conversion from an HFS to zFS file system.
<p><strong>Tip:</strong> Use the BPXWH2Z tool to perform the conversion.
It is an ISPF-based tool that migrates HFS file systems to zFS file
systems. Using its panel interface, you can alter the space allocation,
placement, SMS classes, and data set names. A HELP panel is provided.
With this tool, you can:</p>
<ul>
<li>Migrate HFS file systems (both mounted and unmounted) to zFS file
systems. If the HFS being migrated is mounted, the tool automatically
unmounts it and then mounts the new zFS file system on its current
mount point.</li>
<li>Define zFS aggregates by default to be approximately the same
size as the  HFS. The new allocation size can also be increased or
decreased.</li>
<li>Have the migration run in TSO foreground or UNIX background.</li></ul>
<p>You can use the JCL sample ISPBTCH in SYS1.SAMPLIB to
invoke BPXWH2Z as an ISPF batch job. Before you run the job, read
the notes section.  When you run BPXWH2Z on your z/OS V1R13 system, it uses the z/OS V1R13 level of the <strong>pax</strong> command.
This level was enhanced in z/OS V1R7
for sparse file support and other characteristics that are of concern
when migrating from an HFS to zFS file system. You can manually migrate
from an HFS to zFS file system without using the tool. However, you
would need to allocate and format the target zFS file systems.</p>
<p><strong>Requirement:</strong> The BPXWH2Z tool requires the zFS address
space to be operational. Therefore, before attempting to migrate existing
HFS to zFS file systems using BPXWH2Z, make sure that the zFS address
space has been successfully configured and initialized.</p>
<p><strong>Tip:</strong> Consider migrating the sysplex root file system
to zFS after you IPL z/OS V1R12.
You can now dynamically migrate the HFS sysplex root in a shared file
system configuration to zFS while the root is in use, without disrupting
workloads. Before z/OS V1R10,
you could not migrate without disrupting active workloads. Although
the shared file system configuration is required, the sysplex can
be a single system. For the steps involved in migrating the sysplex
root file system from HFS to zFS, see below.</p></li>
<li>Change policies and scripts, and so forth, to reflect the change
from the HFS file system to zFS file system.
<p><strong>Tip:</strong> Use
the RMF Monitor III option to
report on zFS activity.</p></li></ol>
<p id="rootmig"><strong>Migrating the sysplex root file system
from HFS to zFS after IPLing z/OS V1R12:</strong></p><a id="idx1022"></a>
<p>Before you begin the migration:</p>
<ul>
<li>Ensure that the following requirements have been met:
<ul>
<li>All systems in the sysplex are at the V1R12 level.</li>
<li>The current sysplex root file system PFS, and the new sysplex
root file system PFS, are up in all the systems in shared file system
configuration.</li></ul></li>
<li>Be aware of the following restrictions:
<ul>
<li>The current sysplex root file system must be mounted as a read-only
file system.</li>
<li>The systems that do not meet the requirements for this migration
action cannot join the sysplex during the sysplex root file system
migration processing, but they can join the sysplex after the sysplex
root migration has completed.</li>
<li>The current sysplex root and the new sysplex root must be either
HFS or zFS in any combination. If the new sysplex root is zFS, then
 it must be HFS-compatible.</li>
<li>The sysplex root or any directories on it cannot have been exported
by the DFS or
SMB server.</li></ul></li>
<li>Note the following:
<ul>
<li>Remote NFS mounts of the sysplex root or any directories on it
are considered active use of the current sysplex root file system.</li>
<li>During the migration, the new zFS sysplex root file system must
not be HSM-migrated, mounted, or in use.</li>
<li>Mount parameters are preserved during the migration or replacement
of the sysplex root file system of the same file system type (PFS).
They are dropped if the file system type is different.</li>
<li>Directories, data, files, and links are not copied from one file
system to another.</li></ul></li></ul>
<p>Perform the migration as follows:</p>
<ol type="1">
<li>Ensure that a file system has been mounted read-only as
the current sysplex root file system. When the root is mounted read-only,
there are no function-shipping clients as long as physical
paths to the DASD are available to each system. To verify that there
are no function-shipping clients, issue: 
<pre class="xmp"><code>D OMVS,F,NAME=root_file_system_name</code></pre>You
should see CLIENT=N on each system.</li>
<li>Allocate and set up the new zFS sysplex root file system: 
<ol type="a">
<li>Create a new zFS file system to be used as the new sysplex root
file system. >z/OS Distributed File Service zSeries File System Administration</a> discusses
creating and managing zFS file systems. 
<p><strong>Rules:</strong> </p>
<ul>
<li>The UID, GID and the permission bits of the root directory in
the new sysplex root file system must be same as the root directory
in the current sysplex root file system.</li>
<li>If the SECLABEL class is active and the MLFSOBJ option is active,
the security label for the new zFS file system must match the assumed
security label of the current sysplex root file system.</li></ul></li>
<li>On the new sysplex root file system, set up the active mount points
and the symbolic links. The mount points and symbolic links must be
the same as the ones on the current sysplex root file system. You
can set them up either (1) manually or (2) by using the <span class="pk">pax</span> shell
command to populate the new sysplex root file system using the existing
sysplex root as a source. To do it manually, create a mount point
in the existing sysplex root (for example, /newroot) and mount the
new sysplex root file system in the MODE(RDWR) on that mount point.
After mounting the new sysplex root file system, manually issue MKDIRs
and ln -s to create the mount point directories and symbolic links
similar to the existing sysplex root file system. Note that the new
sysplex root file system must contain all active mount points and
symbolic links exactly as on the existing sysplex root file system.</li>
<li>Use the <span class="pk">pax</span> shell command to populate the new file system,
using the existing sysplex root as a source.
<p><strong>Example:</strong> </p>
<pre class="xmp"><code>cd /
pax -wr -pe -XCM ./ /newroot</code></pre><p class="indatacontent"> For more information about using <span class="pk">pax</span> to
copy data from an HFS file system to a zFS file system, see >z/OS Distributed File Service zSeries File System Administration</a>.</p></li>
<li>Unmount the new zFS file system.</li></ol></li>
<li>On any system in the shared file system configuration,
issue:
<pre class="xmp"><code>F OMVS,NEWROOT=new.root.file.system.name,COND=&lt;Yes|No></code></pre>
<dl>
<dt class="bold">YES</dt>
<dd>Proceed conditionally. The system checks for active usage in
the current sysplex root file system and reports the active usage
in a BPXF245I message. If file activity is found, the command
fails with EBUSY return code and JrActivityFound reason code. If file
activity is not found, the command continues processing to replace
the sysplex root. YES is the default.
</dd>
<dt class="bold">NO</dt>
<dd>Proceed unconditionally. The system checks for active usage
in the current sysplex root file system and reports the active usage
in a BPXF245I message. Replacement of the sysplex root file
system will continue.
</dd>
</dl>The migration of  the sysplex root file system will begin. During
the migration, active connections to files and directories in the
current sysplex root file system are broken.
<p>After the migration
completes:</p>
<ul>
<li>The root CWD(&lsquo;/') is updated on all systems in the sysplex
to point to the new sysplex root file system.</li>
<li>New opens go to the new sysplex root file system.  The current
sysplex root for the root directory is replaced for all  processes
in all systems.  The current directory for root directory is replaced
for any processes using it</li>
<li>Old connections in the previous sysplex root file system might get
EIO errors.</li></ul></li>
<li>Update the TYPE parameter and name of the sysplex root
file system in the BPXPRM<var class="pv">xx</var> member of SYS1.PARMLIB.</li></ol>
<p><strong>Reference information:</strong> </p>
<ul>
<li>For more information about the HFS and zFS file systems, see >z/OS UNIX System Services Planning</a>.</li>
<li>To read about setting up zFS, see >z/OS Distributed File Service zSeries File System Administration</a>.</li>
<li>For information about the <strong>pax</strong> command, see >z/OS UNIX System Services Command Reference</a>.</li></ul>
<h2 id="wq585">z/OS UNIX actions to perform before the first IPL of z/OS V1R13</h2>
<p>This topic describes z/OS UNIX migration actions that you
can perform after you have installed z/OS V1R13
but before the first time you IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.<a id="idx1023"></a><a id="idx1024"></a><a id="idx1025"></a><a id="idx1026"></a><a id="idx1027"></a><a id="idx1028"></a></p>
<h3 id="bpxmount">Update invocations of MOUNT statements in the BPXPRMxx parmlib
member</h3>
<p><strong>Description:</strong> Before z/OS V1R13, if the MOUNT statement in the BPXPRM<var class="pv">xx</var> member
of SYS1.PARMLIB was first processed by a system other than the specified
target owner, the MOUNT processing was function-shipped to
the target owner. Starting with z/OS V1R13,
if the MOUNT statement specifies a SYSNAME() keyword, the mount request
is ignored during file system initialization and F BPXOINIT,FILESYS=REINIT
processing if the SYSNAME() value specifies a different target owner
system. The file system is then automatically mounted locally after
the MOUNT statement is processed on the target system. The MOUNT statements
in BPXPRM<var class="pv">xx</var> continues to be processed as part of SET OMVS
and SETOMVS command processed without any changes; that is, the MOUNT
processing continues to be function-shipped to the specified
SYSNAME() target owner system.<a id="idx1029"></a></p>
<table id="wq586" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because required file systems might not
be mounted.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you have a BPXPRM<var class="pv">xx</var> parmlib
member that contains MOUNT statements with a SYSNAME() keyword specifying
a specific target name, select one of the following actions: </p>
<ol type="1">
<li>Verify that the BPXPRM<var class="pv">xx</var> member is also specified as
a z/OS UNIX parmlib member for the specified target systems.</li>
<li>Move the MOUNT statements from that BPXPRM<var class="pv">xx</var> member to
a BPXPRM<var class="pv">xx</var> member that is used by the target owner system.</li></ol>
<p>Note that specifying SYSNAME(&amp;SYSNAME) always resolves to the
system name of the local system; the MOUNT statement is processed
as a result.</p>
<p><strong>Reference information:</strong> See &quot;Customizing
BPXPRM<var class="pv">xx</var> for a shared file system&quot; in >z/OS UNIX System Services Planning</a> for
a description of the <a href="../com.ibm.zos.r13.bpxb200/sysname.htm">SYSNAME()</a> keyword for the BPXPRM<var class="pv">xx</var> MOUNT
statement.</p>
<h3 id="symblinks">Accommodate changes to support read-only z/OS root for the z/OS UNIX System
Services cron, mail, and uucp utilities</h3>
<p><strong>Description:</strong> Before z/OS V1R13, for each new release, certain post-installation
activities had to be done for the z/OS UNIX System Services <span class="pk">cron</span>, <span class="pk">mail</span>,
and <span class="pk">uucp</span> utilities in order for the root file system to be
mounted read-only. Starting in z/OS V1R13,
the <samp class="xph">/usr/lib/cron</samp>, <samp class="xph">/usr/mail</samp>, and <samp class="xph">/usr/spool</samp> directories
are provided as symbolic links. Note that this migration action does
not affect other mail utilities such <span class="pk">tsmail</span>, <span class="pk">mailx</span>,
and Communications Server <span class="pk">sendmail</span>.<a id="idx1030"></a></p>
<table id="wq588" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if either of the following is true:
<ul>
<li>You have performed the post-installation activities to make <span class="pk">uucp</span>, <span class="pk">cron</span>,
or <span class="pk">mail </span> supported for a read-only z/OS root. You do not necessarily have to be running
with the z/OS root as read
only but only have the post-installation customization as described
in >z/OS UNIX System Services Planning</a>.</li>
<li>You have used <span class="pk">uucp</span>, <span class="pk">cron</span>, or <span class="pk">mail </span> facilities
and have not performed the post-installation customization as described
in >z/OS UNIX System Services Planning</a>.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>
<ul>
<li><span>Because the new z/OS V1R13
symbolic links are directed to a system-specific file system, other
file systems are not affected by this change.</span>  When shared in
read-only mode, the z/OS root
will contain the <samp class="xph">/var</samp> symbolic links.</li>
<li>If you use any of the utilities (<span class="pk">uucp</span>, <span class="pk">cron</span>,
or <span class="pk">mail </span>), then review any files that these utilities produce,
such as logs. Now that the symbolic links, by default, point to the <samp class="xph">/var</samp> location,
ensure that you have room for these utility-produced files in <samp class="xph">/var</samp>.
 This might mean: (1) creating a separate file system for files (such
as <samp class="xph">/var/spool</samp>, as recommended in >z/OS UNIX System Services Planning</a>),
(2) moving existing separate file systems you already have to be mounted
under <samp class="xph">/var</samp> (from<samp class="xph">/etc</samp>, for instance), or (3)
enlarging your <samp class="xph">/var</samp> file system if you don't have separately
mounted file systems for these utilities.</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>Use check ZOSMIGV1R13_RO_SYMLINKS, available
with APAR OA35605 and APAR OA35636.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> </p>
<div>
<div class="notetitle" id="wq589">Note:</div>
<div class="notebody">While
this migration action should be performed before the first IPL of z/OS V1R13, the changes to use <samp class="xph">/var</samp> for
this support can be done at any time. Although previous documentation
had shown the use of <samp class="xph">/etc n</samp> examples, after further consideration,
we now recommend using <samp class="xph">/var</samp> for these utilities.</div></div>
<ol type="1">
<li><span>If you currently use /etc or another directory
for post-installation customization for these utilities</span>, decide
if you want to continue to use those directories or move to the /var
structure that is provided with z/OS V1R13.
Moving to the /var structure is recommended because: 
<ul>
<li>You can minimize any subsequent post-installation customization,
since the symbolic links to <samp class="xph">/var</samp> will be provided for you
by IBM.  Continued use of non-/var
directories may mean post-installation work every time to remove the
delivered structure and replace it with your own.</li>
<li>Continued use of <samp class="xph">/etc</samp> (or another directory),
requires you to manage and maintain the symbolic links required from <samp class="xph">/var</samp> to
that directory, which is &quot;double symlinking.&quot;  This &quot;double
symlinking&quot; might be confusing for those that maintain the system.</li></ul></li>
<li>If you use<samp class="xph"> /var</samp> for your post-installation customization,
then ensure that the <samp class="xph">/var</samp> file system to be mounted at
the z/OS V1R13 level of <samp class="xph">/var</samp> (or
subdirectories shown below) contains the following directories or
files for the utilities you are using.  These will now be referenced
by symbolic links in the z/OS V1R13
root file system when cron, mail, and uucp are used:
<ul>
<li><samp class="xph">/var/mail</samp></li>
<li><samp class="xph">/var/spool</samp></li>
<li><samp class="xph">/var/spool/cron</samp></li>
<li><samp class="xph">/var/spool/locks</samp></li>
<li><samp class="xph">/var/spool/cron/atjobs</samp></li>
<li><samp class="xph">/var/spool/cron/crontabs</samp></li>
<li><samp class="xph">/var/spool/uucp</samp></li>
<li><samp class="xph">/var/spool/uucppublic</samp></li>
<li><samp class="xph">/var/spool/uucp/.Xqtdir</samp></li>
<li><samp class="xph">/var/spool/uucp/.Sequence</samp></li>
<li><samp class="xph">/var/spool/uucp/.Status</samp></li>
<li><samp class="xph">/var/cron</samp></li>
<li><samp class="xph">/var/uucp/Systems </samp></li>
<li><samp class="xph">/var/uucp/Devices</samp></li>
<li><samp class="xph">/var/uucp/Dialers</samp></li>
<li><samp class="xph">/var/uucp/Dialcodes</samp></li>
<li><samp class="xph">/var/uucp/Permissions</samp></li>
<li><samp class="xph">/var/uucp/config </samp></li></ul>
<p><span>Note that the <samp class="xph">/var</samp> file system
provided by ServerPac will contain these directories but not the files,
because the files are provided when the utilities are configured and
used.</span> If you use to use the ServerPac <samp class="xph">/var</samp>  and add
your files to that <samp class="xph">/var</samp> file system, that is acceptable,
as documented in <a href="#at3gend">Migrate /etc and /var system control files</a>. This action is similar to
how you would merge an <samp class="xph">/var</samp> file system provided by Server
Pac with an existing file system.</p>
<p>If you have any user files
under <samp class="xph">/usr/spool</samp>, <samp class="xph">/usr/lib/cron</samp>, or <samp class="xph">/usr/mail</samp> in
the root file system (that is, they have not been symlinked under <samp class="xph">/var</samp> or
another directory to support the read-only root), then those
files must be moved to <samp class="xph">/var/spool,</samp> <samp class="xph">/var/cron</samp>,
or <samp class="xph">/var/mail</samp> (or another directory besides the <samp class="xph">/var</samp> that
you choose).</p></li></ol>
<p><strong>Reference information:</strong> >z/OS UNIX System Services Planning</a>.</p>
<h2 id="wq591">z/OS UNIX actions to perform after the first IPL of z/OS V1R13</h2>
<p>This topic describes z/OS UNIX migration actions that you
can perform only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p><a id="idx1031"></a><a id="idx1032"></a><a id="idx1033"></a><a id="idx1034"></a><a id="idx1035"></a><a id="idx1036"></a>
<h3 id="invrexx">Discontinue use of invalid REXX variables in z/OS UNIX syscalls</h3>
<p><strong>Description:</strong> Before z/OS V1R13, issuing z/OS UNIX syscalls with invalid REXX
variables might not generate an error message. Starting in z/OS V1R13, error messages are
issued.<a id="idx1037"></a></p>
<table id="wq592" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX System Services.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes. Using invalid REXX variables could cause
problems that might not be noticed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> If you have REXX programs
with multiple syscalls that use the (<var class="pv">rexx-variable</var>)
format of passing variables and do not check RETVAL and or ERRNO upon
return, follow these steps.</p>
<ol type="1">
<li>Run these programs.</li>
<li>Fix parsing errors as they occur, replacing invalid REXX variables
with valid ones. The error number will identify the invalid REXX variable.
Note that REXX variable names cannot start with a digit or include
arithmetic operators. For example, x*y is an invalid REXX variable.
<ul>
<li>If the program produces a REXX parsing error, the error will be:
<pre class="xmp"><code>IRX0041I Error running ....... line xx:  ......</code></pre> 
<p>This
is a TSO REXX error message.</p></li>
<li> If the program produces a z/OS UNIX syscall parsing error, the
error code will be -21,-22,..., as described under the section "Returned
from the SYSCALL environment" in the USS REXX documentation.</li></ul></li></ol>
<p><strong>Reference information:</strong> See >z/OS Using REXX and z/OS UNIX System Services</a> for
information about the error message.</p>
<h3 id="skulker">Consider skulker invocations because of updated restriction</h3>
<p><strong>Description:</strong> Before z/OS V1R12, if the <span class="pk">skulker</span> command was
issued and there were objects in the specified directory (and in any
subdirectories if the <span class="pk">-r</span> option was used) whose path name
included single quotes or a newline character, those objects were
not deleted, a warning message (<strong>skulker terminated
without removing any files, because of the following pathnames that
include a single quote or newline</strong>) was issued, and all processing
stopped. Starting with z/OS V1R12,
a warning message is not issued, those objects are ignored, and processing
continues. <a id="idx1038"></a></p>
<table id="wq594" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are concerned about not getting
a warning message if objects in the specified directory or subdirectories
whose path name includes single quotes or a newline character are
found.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Use the <span class="pk">find</span> command
to determine if there are any objects in the specified directory or
subdirectories whose path name includes single quotes or a newline
character. Do not use the <span class="pk">find</span> command to locate the objects
whose path name include single quotes or a newline character as a
standard practice before using the <span class="pk">skulker</span> command if you
want the directories removed because issuing the <span class="pk">find</span> command
will modify the access times of directories that are part of that <span class="pk">find</span> request.</p>
<p><strong>Reference information:</strong> For information about
the <span class="pk">find</span> and <span class="pk">skulker</span> commands, see >z/OS UNIX System Services Command Reference</a>.</p>
<h3 id="bpxuniq">Use the BPX.UNIQUE.USER profile instead of BPX.DEFAULT.USER</h3>
<p><strong>Description:</strong>  Before z/OS V1R11, if the BPX.DEFAULT.USER profile in the
FACILITY class was defined, users who accessed z/OS UNIX services
who did not have an OMVS user or group segment were assigned the default
OMVS segments for the length of the user session. All users of the
default OMVS segments shared the same UID and GID. As of z/OS V1R11, if BPX.UNIQUE.USER
has been defined, users who access z/OS UNIX services who do not have an
OMVS user or group segment are automatically assigned an OMVS segment
with a unique UID and GID. The new OMVS segments are added to the
user and group profiles in the RACF database.</p>
<div>
<div class="notetitle" id="wq595">Note:</div>
<div class="notebody">You need AIM Stage 3 to use the BPX.UNIQUE.USER
profile. You can run the IRRIRA00 utility to determine the current
AIM Stage in your RACF database.</div></div><a id="idx1039"></a><a id="idx1040"></a>
<table id="wq596" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12
and z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because z/OS V1R13 is planned to be the last release to
support BPX.DEFAULT.USER (as previewed in z/OS V1R13 Software Announcement 211-007, dated
February 15, 2011). IBM recommends
that you either use the BPX.UNIQUE.USER support, or assign unique
UIDs to users who need them and assign GIDs for their groups. The
use of BPX.UNIQUE.USER increases security because shared IDs are not
used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take:</strong> Follow the steps in >z/OS UNIX System Services Planning</a> to
set up the BPX.UNIQUE.USER profile. If BPX.DEFAULT.USER has not been
deleted, BPX.UNIQUE.USER takes precedence when default OMVS segments
are used.</p>
<p>To remove the BPX.DEFAULT.USER profile, use the following RACF commands:</p>
<pre class="xmp"><code>RDELETE FACILITY BPX.DEFAULT.USER 
SETROPTS RACLIST(FACILITY) REFRESH</code></pre>
<p><strong>Reference information:</strong> </p>
<ul>
<li>>z/OS UNIX System Services Planning</a></li>
<li>>z/OS Security Server RACF Security Administrator&rsquo;s Guide</a></li></ul>
<h1 id="wq597">Index for Migration</h1>
<a name="IDX0_00" href="#IDX1_00">Special characters</a><br />
<a name="IDX0_01" href="#IDX1_01">Numerics</a><br />
<a name="IDX0_41" href="#IDX1_41">A</a>
<a name="IDX0_42" href="#IDX1_42">B</a>
<a name="IDX0_43" href="#IDX1_43">C</a>
<a name="IDX0_44" href="#IDX1_44">D</a>
<a name="IDX0_45" href="#IDX1_45">E</a>
<a name="IDX0_46" href="#IDX1_46">F</a>
<a name="IDX0_47" href="#IDX1_47">G</a>
<a name="IDX0_48" href="#IDX1_48">H</a>
<a name="IDX0_49" href="#IDX1_49">I</a>
<a name="IDX0_4A" href="#IDX1_4A">J</a>
<a name="IDX0_4B" href="#IDX1_4B">K</a>
<a name="IDX0_4C" href="#IDX1_4C">L</a>
<a name="IDX0_4D" href="#IDX1_4D">M</a>
<a name="IDX0_4E" href="#IDX1_4E">N</a>
<a name="IDX0_4F" href="#IDX1_4F">O</a>
<a name="IDX0_50" href="#IDX1_50">P</a>
<a name="IDX0_51" href="#IDX1_51">Q</a>
<a name="IDX0_52" href="#IDX1_52">R</a>
<a name="IDX0_53" href="#IDX1_53">S</a>
<a name="IDX0_54" href="#IDX1_54">T</a>
<a name="IDX0_55" href="#IDX1_55">U</a>
<a name="IDX0_56" href="#IDX1_56">V</a>
<a name="IDX0_57" href="#IDX1_57">W</a>
<a name="IDX0_58" href="#IDX1_58">X</a>
<a name="IDX0_5A" href="#IDX1_5A">Z</a>
<hr></hr>
<strong><a name="IDX1_00" href="#IDX0_00">Special characters</a></strong>
<ul class="indexlist">
<li><a href="#idx991" class="indexlink">&amp;lt;ogus index entry></a>
</li>
<li><a href="#idx739" class="indexlink">.bak file system</a>
</li>
<li><a href="#idx100" class="indexlink">/etc directory, migrating files in</a>
</li>
<li><a href="#idx318" class="indexlink">&lt;bogus index entry></a>
</li>
<li><a href="#idx827" class="indexlink">*S main,FLUSH</a>
</li>
<li><a href="#idx1011" class="indexlink">/usr/sbin/mount invocations</a>
</li>
<li>/usr/sbin/unmount invocations
<a href="#idx1012" class="indexlink">(1)</a>, <a href="#idx1029" class="indexlink">(2)</a>
</li>
<li><a href="#idx101" class="indexlink">/var directory, migrating files in</a>
</li>
</ul>
<strong><a name="IDX1_01" href="#IDX0_01">Numerics</a></strong>
<ul class="indexlist">
<li><a href="#idx51" class="indexlink">3270 PC File Transfer Program, no migration actions for</a>
</li>
<li><a href="#idx564" class="indexlink">3800 Printing Subsystem, preparing to use</a>
</li>
<li><a href="#idx565" class="indexlink">3900 Printing Subsystem, preparing to use</a>
</li>
<li>64-bit mode
<ul class="indexlist">
<li><a href="#idx700" class="indexlink">DFSMS macros</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_41" href="#IDX0_41">A</a></strong>
<ul class="indexlist">
<li><a href="#idx538" class="indexlink">ACDS (active control data set), ensuring integrity of</a>
</li>
<li><a href="#idx539" class="indexlink">active control data set (ACDS), ensuring integrity of</a>
</li>
<li><a href="#idx422" class="indexlink">additional parameter</a>
</li>
<li><a href="#idx136" class="indexlink">address spaces, new</a>
</li>
<li><a href="#idx442" class="indexlink">addrinfo storage</a>
</li>
<li><a href="#idx624" class="indexlink">ADRUFO block</a>
</li>
<li>after first IPL, migration actions
<ul class="indexlist">
<li><a href="#idx375" class="indexlink">BCP</a>
</li>
<li><a href="#idx479" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx517" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx696" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx722" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx757" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx788" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx797" class="indexlink">ISPF</a>
</li>
<li><a href="#idx808" class="indexlink">JES2</a>
</li>
<li><a href="#idx857" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx882" class="indexlink">RMF</a>
</li>
<li><a href="#idx903" class="indexlink">SDSF</a>
</li>
<li><a href="#idx952" class="indexlink">Security Server</a>
</li>
<li><a href="#idx281" class="indexlink">sysplex</a>
</li>
<li><a href="#idx987" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1001" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1033" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>AIRSHREP.sh
<ul class="indexlist">
<li><a href="#idx360" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li><a href="#idx346" class="indexlink">ALLOWCMD(Y) keyword</a>
</li>
<li><a href="#idx23" class="indexlink">Alternate Library for REXX, no migration actions for</a>
</li>
<li><a href="#idx390" class="indexlink">AMBLIST command</a>
</li>
<li><a href="#idx407" class="indexlink">ancillary input queue (AIQ)</a>
</li>
<li><a href="#idx792" class="indexlink">aopsetup, running</a>
</li>
<li>AR mode
<ul class="indexlist">
<li><a href="#idx701" class="indexlink">DFSMS macros</a>
</li>
</ul>
</li>
<li><a href="#idx693" class="indexlink">ARCBDEXT</a>
</li>
<li><a href="#idx189" class="indexlink">ARCH(8) compiler option</a>
</li>
<li>ARRCAT
<ul class="indexlist">
<li><a href="#idx712" class="indexlink">resource contention, when starting CDS backup</a>
</li>
</ul>
</li>
<li><a href="#idx416" class="indexlink">attack detection</a>
</li>
<li><a href="#idx370" class="indexlink">Auto-reply for WTORs</a>
</li>
<li><a href="#idx828" class="indexlink">Automatic flush</a>
</li>
<li>automation
<ul class="indexlist">
<li><a href="#idx331" class="indexlink">CSVLLAxx member</a>
</li>
<li><a href="#idx330" class="indexlink">library lookaside (LLA)</a>
</li>
</ul>
</li>
<li><a href="#idx992" class="indexlink">AVGREC option of TSO/E</a>
</li>
</ul>
<strong><a name="IDX1_42" href="#IDX0_42">B</a></strong>
<ul class="indexlist">
<li><a href="#idx784" class="indexlink">basic mode to extended mode, IP PrintWay migration from</a>
</li>
<li>BCP migration actions
<ul class="indexlist">
<li><a href="#idx373" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx307" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx286" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx298" class="indexlink">BCPii</a>
</li>
<li><a href="#idx24" class="indexlink">BDT, no migration actions for</a>
</li>
<li><a href="#idx25" class="indexlink">BDT File-to-File, no migration actions for</a>
</li>
<li><a href="#idx26" class="indexlink">BDT SNA NJE, no migration actions for</a>
</li>
<li><a href="#idx832" class="indexlink">before first IPL</a>
</li>
<li>before first IPL, migration actions
<ul class="indexlist">
<li><a href="#idx309" class="indexlink">BCP</a>
</li>
<li><a href="#idx454" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx495" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx558" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx716" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx749" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx88" class="indexlink">general</a>
</li>
<li><a href="#idx771" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx823" class="indexlink">JES3</a>
</li>
<li><a href="#idx836" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx866" class="indexlink">Library Server</a>
</li>
<li><a href="#idx874" class="indexlink">RMF</a>
</li>
<li><a href="#idx894" class="indexlink">SDSF</a>
</li>
<li><a href="#idx937" class="indexlink">Security Server</a>
</li>
<li><a href="#idx274" class="indexlink">sysplex</a>
</li>
<li><a href="#idx981" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1025" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>before installing, migration actions
<ul class="indexlist">
<li><a href="#idx288" class="indexlink">BCP</a>
</li>
<li><a href="#idx398" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx491" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx530" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx734" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx57" class="indexlink">general</a>
</li>
<li><a href="#idx764" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx804" class="indexlink">JES2</a>
</li>
<li><a href="#idx817" class="indexlink">JES3</a>
</li>
<li><a href="#idx929" class="indexlink">Security Server</a>
</li>
<li><a href="#idx269" class="indexlink">sysplex</a>
</li>
<li><a href="#idx975" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx997" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1009" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx412" class="indexlink">BIND 9.2.0</a>
</li>
<li><a href="#idx705" class="indexlink">BIND jobs, OAM DB2</a>
</li>
<li><a href="#idx27" class="indexlink">BookManager BUILD, no migration actions for</a>
</li>
<li><a href="#idx28" class="indexlink">BookManager READ, no migration actions for</a>
</li>
<li><a href="#idx1040" class="indexlink">BPX.DEFAULT.USER profile replaced by BPX.UNIQUE.USER</a>
</li>
<li><a href="#idx1039" class="indexlink">BPX.UNIQUE.USER profile</a>
</li>
<li><a href="#idx1013" class="indexlink">BPX1EXM/BPX4EXM callable service</a>
</li>
<li><a href="#idx629" class="indexlink">BSAM</a>
</li>
<li><a href="#idx577" class="indexlink">BSAM, QSAM, and BPAM</a>
</li>
</ul>
<strong><a name="IDX1_43" href="#IDX0_43">C</a></strong>
<ul class="indexlist">
<li><a href="#idx67" class="indexlink">capacity evaluation with zSoftCap</a>
</li>
<li><a href="#idx299" class="indexlink">capacity provisioning</a>
</li>
<li><a href="#idx192" class="indexlink">Capacity Provisioning</a>
</li>
<li>Capacity Provisioning Control Center
<a href="#idx302" class="indexlink">(1)</a>, <a href="#idx389" class="indexlink">(2)</a>
</li>
<li><a href="#idx708" class="indexlink">Catalog Search Interface (CSI)</a>
</li>
<li>CBRSMR1D
<ul class="indexlist">
<li><a href="#idx702" class="indexlink">migration job for DFSMSdfp OAM.</a>
</li>
</ul>
</li>
<li><a href="#idx946" class="indexlink">CDT (class descriptor table) names, RACF</a>
</li>
<li><a href="#idx372" class="indexlink">CEAPRMxx</a>
</li>
<li><a href="#idx853" class="indexlink">CEEPRMxx parmlib member</a>
</li>
<li>CFCC (coupling facility control code)
<ul class="indexlist">
<li><a href="#idx255" class="indexlink">levels</a>
</li>
<li><a href="#idx244" class="indexlink">z990 coexistence requirements</a>
</li>
</ul>
</li>
<li><a href="#idx256" class="indexlink">CFRM policy, updating</a>
</li>
<li><a href="#idx668" class="indexlink">chain rebuild (DFSMShsm), removal of patch preventing SMS MVT</a>
</li>
<li><a href="#idx3" class="indexlink">changes to this document, summary of</a>
</li>
<li><a href="#idx13" class="indexlink">checks, migration health</a>
</li>
<li><a href="#idx843" class="indexlink">CICS system definition file for Language Environment, updating</a>
</li>
<li><a href="#idx29" class="indexlink">CIM, no migration actions for</a>
</li>
<li><a href="#idx379" class="indexlink">CIM Client for Java Version 2</a>
</li>
<li>CIM provider
<ul class="indexlist">
<li><a href="#idx552" class="indexlink">backward-compatible no longer supported by DFSMSrmm</a>
</li>
</ul>
</li>
<li><a href="#idx553" class="indexlink">CIM providers and classes changed for DFSMSrmm</a>
</li>
<li><a href="#idx945" class="indexlink">class descriptor table (CDT) names, RACF</a>
</li>
<li><a href="#idx942" class="indexlink">class name conflicts, RACF</a>
</li>
<li>CLEANUP_TIMEOUT
<ul class="indexlist">
<li><a href="#idx324" class="indexlink">default change</a>
</li>
</ul>
</li>
<li><a href="#idx861" class="indexlink">CLER runtime options report</a>
</li>
<li>CMDS ABEND command
<a href="#idx333" class="indexlink">(1)</a>, <a href="#idx384" class="indexlink">(2)</a>
</li>
<li>CMDS FORCE command
<a href="#idx333" class="indexlink">(1)</a>, <a href="#idx384" class="indexlink">(2)</a>
</li>
<li>coexistence
<ul class="indexlist">
<li><a href="#idx183" class="indexlink">z10 requirements</a>
</li>
<li><a href="#idx243" class="indexlink">z890 requirements</a>
</li>
<li><a href="#idx205" class="indexlink">z9 requirements</a>
</li>
<li><a href="#idx245" class="indexlink">z990 CFCC requirements</a>
</li>
<li><a href="#idx239" class="indexlink">z990 requirements</a>
</li>
</ul>
</li>
<li>command output
<a href="#idx685" class="indexlink">(1)</a>, <a href="#idx690" class="indexlink">(2)</a>
</li>
<li><a href="#idx540" class="indexlink">COMMDS (common communications data set), ensuring integrity of</a>
</li>
<li><a href="#idx338" class="indexlink">COMMNDxx</a>
</li>
<li><a href="#idx541" class="indexlink">common communications data set (COMMDS), ensuring integrity of</a>
</li>
<li>Communications Server migration actions
<ul class="indexlist">
<li><a href="#idx477" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx452" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx396" class="indexlink">before installing</a>
</li>
<li><a href="#idx400" class="indexlink">Before installing</a>
</li>
</ul>
</li>
<li><a href="#idx30" class="indexlink">Communications Server Security Level 3, no migration actions for</a>
</li>
<li>Compatibility Support feature, z/OS V1R4 z990
<a href="#idx219" class="indexlink">(1)</a>, <a href="#idx226" class="indexlink">(2)</a>
</li>
<li>CON=
<ul class="indexlist">
<li><a href="#idx335" class="indexlink">default changes</a>
</li>
</ul>
</li>
<li>Connection Manager
<ul class="indexlist">
<li><a href="#idx1018" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li>CONSOL<var class="pv">xx</var>
<ul class="indexlist">
<li><a href="#idx300" class="indexlink">INIT, DEFAULT, HARDCOPY and CONSOLE keyword statements require blank delimiter.</a>
</li>
</ul>
</li>
<li><a href="#idx344" class="indexlink">console commands and problem determination</a>
</li>
<li><a href="#idx346" class="indexlink">CONSOLxx</a>
</li>
<li><a href="#idx533" class="indexlink">control data sets, migrating SMS</a>
</li>
<li><a href="#idx862" class="indexlink">conversion table removal</a>
</li>
<li><a href="#idx631" class="indexlink">COPYDUMP</a>
</li>
<li><a href="#idx567" class="indexlink">core image of DFSMSdss Stand-Alone Services, building</a>
</li>
<li><a href="#idx254" class="indexlink">coupling facility control code (CFCC) levels</a>
</li>
<li>CPCC
<a href="#idx301" class="indexlink">(1)</a>, <a href="#idx388" class="indexlink">(2)</a>
</li>
<li><a href="#idx68" class="indexlink">CPU evaluation with zSoftCap</a>
</li>
<li><a href="#idx228" class="indexlink">Cryptographic CP Assist Support, z990</a>
</li>
<li>Cryptographic Services migration actions
<ul class="indexlist">
<li><a href="#idx515" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx493" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx489" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx449" class="indexlink">CSA shortage</a>
</li>
<li><a href="#idx844" class="indexlink">CSD (CICS system definition) file for Language Environment, updating</a>
</li>
<li><a href="#idx411" class="indexlink">CSFPDVK and CSFPDMK</a>
</li>
<li><a href="#idx709" class="indexlink">CSI (Catalog Search Interface)</a>
</li>
<li><a href="#idx447" class="indexlink">CSM buffer</a>
</li>
<li>CSVLLAxx member
<ul class="indexlist">
<li><a href="#idx329" class="indexlink">automation</a>
</li>
</ul>
</li>
<li><a href="#idx306" class="indexlink">CSVRTLS</a>
</li>
<li>CTIGRSxx
<ul class="indexlist">
<li><a href="#idx348" class="indexlink">default change</a>
</li>
</ul>
</li>
<li><a href="#idx365" class="indexlink">CUNIDHC2</a>
</li>
</ul>
<strong><a name="IDX1_44" href="#IDX0_44">D</a></strong>
<ul class="indexlist">
<li><a href="#idx850" class="indexlink">D CEE</a>
</li>
<li><a href="#idx547" class="indexlink">DADSM</a>
</li>
<li><a href="#idx574" class="indexlink">DADSM pre- and post-processing</a>
</li>
<li><a href="#idx524" class="indexlink">daily maintenance task for PKI Services</a>
</li>
<li><a href="#idx82" class="indexlink">DASD for z/OS root</a>
</li>
<li>DASD requirements
<ul class="indexlist">
<li><a href="#idx297" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li><a href="#idx534" class="indexlink">data integrity of SMS control data sets</a>
</li>
<li>data set recovery
<ul class="indexlist">
<li><a href="#idx640" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li>data sets
<ul class="indexlist">
<li><a href="#idx130" class="indexlink">deleted</a>
</li>
<li><a href="#idx133" class="indexlink">new</a>
</li>
</ul>
</li>
<li><a href="#idx957" class="indexlink">database templates, updating RACF</a>
</li>
<li><a href="#idx830" class="indexlink">DATINPTR (IATYDAT)</a>
</li>
<li><a href="#idx829" class="indexlink">DATLOREC</a>
</li>
<li><a href="#idx706" class="indexlink">DB2 BIND jobs, OAM</a>
</li>
<li>DCE
<ul class="indexlist">
<li><a href="#idx73" class="indexlink">withdrawal</a>
</li>
</ul>
</li>
<li><a href="#idx754" class="indexlink">DCE/DFS</a>
</li>
<li>default changes
<ul class="indexlist">
<li><a href="#idx710" class="indexlink">Catalog Search Interface (CSI)</a>
</li>
<li><a href="#idx325" class="indexlink">CLEANUP_TIMEOUT parameter of the automatic restart management (ARM)</a>
</li>
<li><a href="#idx334" class="indexlink">CON=</a>
</li>
<li><a href="#idx349" class="indexlink">CTIGRSxx</a>
</li>
<li><a href="#idx645" class="indexlink">DATASETRECOVERY parameter</a>
</li>
<li><a href="#idx730" class="indexlink">DYNALOC/DYNALLOC</a>
</li>
<li><a href="#idx918" class="indexlink">initiators on the SDSF INIT panel</a>
</li>
<li><a href="#idx468" class="indexlink">IP validation checks</a>
</li>
<li><a href="#idx842" class="indexlink">Language Environment options</a>
</li>
<li><a href="#idx1016" class="indexlink">MAXSOCKETS, remove values from AF_UNIX</a>
</li>
<li><a href="#idx728" class="indexlink">MOWRK</a>
</li>
<li><a href="#idx636" class="indexlink">PDA trace</a>
</li>
<li><a href="#idx526" class="indexlink">PKI Services, daily maintenance task</a>
</li>
<li><a href="#idx964" class="indexlink">RACDCERT GENCERT</a>
</li>
<li><a href="#idx965" class="indexlink">RACDCERT REKEY</a>
</li>
<li><a href="#idx369" class="indexlink">REUSASID</a>
</li>
<li><a href="#idx854" class="indexlink">runtime options in CEEPRMxx parmlib member</a>
</li>
<li><a href="#idx437" class="indexlink">UDP request timeout interval duration</a>
</li>
</ul>
</li>
<li><a href="#idx464" class="indexlink">defining key exchange policy rules for a dynamic VPN</a>
</li>
<li><a href="#idx128" class="indexlink">deleted data sets and paths</a>
</li>
<li>devices
<ul class="indexlist">
<li><a href="#idx251" class="indexlink">attaching new</a>
</li>
<li><a href="#idx250" class="indexlink">removing unsupported</a>
</li>
</ul>
</li>
<li><a href="#idx919" class="indexlink">devices on the SDSF PR panel</a>
</li>
<li><a href="#idx910" class="indexlink">devices on the SDSF PUN panel</a>
</li>
<li><a href="#idx911" class="indexlink">devices on the SDSF RDR panel</a>
</li>
<li><a href="#idx753" class="indexlink">DFS client (DFSCM)</a>
</li>
<li>DFSMS migration actions
<ul class="indexlist">
<li><a href="#idx694" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx556" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx528" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>DFSMSdfp OAM.
<ul class="indexlist">
<li><a href="#idx703" class="indexlink">OAM configuration database migration job (CBRSMR1D)</a>
</li>
</ul>
</li>
<li>DFSMSdss cross memory interface
<a href="#idx673" class="indexlink">(1)</a>, <a href="#idx677" class="indexlink">(2)</a>
</li>
<li>DFSMShsm
<a href="#idx637" class="indexlink">(1)</a>, <a href="#idx646" class="indexlink">(2)</a>, <a href="#idx653" class="indexlink">(3)</a>, <a href="#idx671" class="indexlink">(4)</a>, <a href="#idx675" class="indexlink">(5)</a>, <a href="#idx680" class="indexlink">(6)</a>, <a href="#idx686" class="indexlink">(7)</a>
<ul class="indexlist">
<li>CDS backup
<ul class="indexlist">
<li><a href="#idx711" class="indexlink">resource contention, ARCCAT</a>
</li>
</ul>
</li>
<li><a href="#idx638" class="indexlink">data set recovery</a>
<ul class="indexlist">
<li><a href="#idx639" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li>messages
<ul class="indexlist">
<li><a href="#idx654" class="indexlink">ARC0036I (E)</a>
</li>
<li><a href="#idx655" class="indexlink">ARC0503I (E)</a>
</li>
<li><a href="#idx656" class="indexlink">ARC0704I (E)</a>
</li>
<li><a href="#idx648" class="indexlink">ARC1809I</a>
</li>
</ul>
</li>
<li>messages, changed type
<ul class="indexlist">
<li><a href="#idx657" class="indexlink">ARC0036</a>
</li>
<li><a href="#idx658" class="indexlink">ARC0503</a>
</li>
<li><a href="#idx659" class="indexlink">ARC0704</a>
</li>
</ul>
</li>
<li>PDA trace
<ul class="indexlist">
<li><a href="#idx633" class="indexlink">at startup</a>
</li>
</ul>
</li>
<li>tuning
<a href="#idx647" class="indexlink">(1)</a>, <a href="#idx672" class="indexlink">(2)</a>, <a href="#idx676" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li><a href="#idx662" class="indexlink">DFSMShsm: Removal of the patch preventing the SMS MVT chain rebuild</a>
</li>
<li><a href="#idx687" class="indexlink">DFSMShsm LIST</a>
</li>
<li><a href="#idx682" class="indexlink">DFSMShsm QUERY</a>
</li>
<li>DFSMSrmm
<ul class="indexlist">
<li><a href="#idx554" class="indexlink">replace CIM providers and CIM classes</a>
</li>
</ul>
</li>
<li><a href="#idx729" class="indexlink">DFSORT dynamic allocation</a>
</li>
<li>DFSORT migration actions
<ul class="indexlist">
<li><a href="#idx720" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx714" class="indexlink">before first IPL</a>
</li>
</ul>
</li>
<li><a href="#idx726" class="indexlink">DFSORT MOWRK</a>
</li>
<li><a href="#idx361" class="indexlink">DIAGxx parmlib</a>
</li>
<li><a href="#idx7" class="indexlink">direct migration</a>
</li>
<li>Distributed Computing Environment
<ul class="indexlist">
<li><a href="#idx74" class="indexlink">withdrawal</a>
</li>
</ul>
</li>
<li>Distributed File Service migration actions
<ul class="indexlist">
<li><a href="#idx755" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx747" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx732" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>distributed identify filter
<a href="#idx932" class="indexlink">(1)</a>, <a href="#idx947" class="indexlink">(2)</a>, <a href="#idx960" class="indexlink">(3)</a>
</li>
<li><a href="#idx563" class="indexlink">DLLs (dynamic link libraries) with Language Environment</a>
</li>
<li><a href="#idx820" class="indexlink">DLOG, JES3</a>
</li>
<li><a href="#idx413" class="indexlink">DNS and BIND 9.2.0</a>
</li>
<li><a href="#idx630" class="indexlink">DUMP</a>
</li>
<li><a href="#idx315" class="indexlink">dump, reassembling stand-alone</a>
</li>
<li><a href="#idx290" class="indexlink">dump data sets, stand-alone</a>
</li>
<li><a href="#idx943" class="indexlink">duplicate class names, RACF</a>
</li>
<li><a href="#idx562" class="indexlink">dynamic link libraries with Language Environment</a>
</li>
<li><a href="#idx467" class="indexlink">dynamic VPN, defining key exchange policy rules</a>
</li>
</ul>
<strong><a name="IDX1_45" href="#IDX0_45">E</a></strong>
<ul class="indexlist">
<li>EAV enhancements
<ul class="indexlist">
<li><a href="#idx576" class="indexlink">modify application programs for</a>
</li>
</ul>
</li>
<li>EEPLEVENTSPECIFICINFO
<ul class="indexlist">
<li><a href="#idx304" class="indexlink">BCP</a>
</li>
</ul>
</li>
<li><a href="#idx512" class="indexlink">enabling SSL V3 and TLS session renegotiation for System SSL</a>
</li>
<li><a href="#idx14" class="indexlink">Enhanced PSP Tool</a>
</li>
<li><a href="#idx406" class="indexlink">Enterprise Extender (EE) traffic and QDIO inbound workload queueing</a>
</li>
<li><a href="#idx475" class="indexlink">Enterprise Extender connection health</a>
</li>
<li><a href="#idx15" class="indexlink">EPSPT</a>
</li>
<li><a href="#idx878" class="indexlink">ERB812I</a>
</li>
<li><a href="#idx879" class="indexlink">ERB813I</a>
</li>
<li><a href="#idx31" class="indexlink">EREP, no migration actions for</a>
</li>
<li><a href="#idx32" class="indexlink">ESCON Director Support, no migration actions for</a>
</li>
<li><a href="#idx319" class="indexlink">ESQA</a>
</li>
<li><a href="#idx367" class="indexlink">ETC, EWLM transaction class name</a>
</li>
<li>everyone, migration actions for
<ul class="indexlist">
<li><a href="#idx89" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx55" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx366" class="indexlink">EWLM transaction class name (ETC)</a>
</li>
<li>exit routines
<ul class="indexlist">
<li><a href="#idx622" class="indexlink">ADRUIXIT</a>
</li>
<li><a href="#idx691" class="indexlink">ARCBDEXT</a>
</li>
<li><a href="#idx625" class="indexlink">EIOP03</a>
</li>
<li><a href="#idx627" class="indexlink">EIOP06</a>
</li>
<li><a href="#idx418" class="indexlink">FTCHKPWD</a>
</li>
<li><a href="#idx780" class="indexlink">IEFUSI</a>
</li>
<li>IEFXVNSL
<ul class="indexlist">
<li><a href="#idx606" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx350" class="indexlink">IFASMFDL</a>
</li>
<li><a href="#idx352" class="indexlink">IFASMFDP</a>
</li>
<li>IFG0193C
<ul class="indexlist">
<li><a href="#idx610" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0193G
<ul class="indexlist">
<li><a href="#idx620" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0199I
<ul class="indexlist">
<li><a href="#idx618" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019FS
<ul class="indexlist">
<li><a href="#idx588" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019FV
<ul class="indexlist">
<li><a href="#idx586" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019LA
<ul class="indexlist">
<li><a href="#idx582" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019VM
<ul class="indexlist">
<li><a href="#idx584" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0553C
<ul class="indexlist">
<li><a href="#idx612" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG055FE
<ul class="indexlist">
<li><a href="#idx590" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0EX0B
<ul class="indexlist">
<li><a href="#idx614" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IGGPOST0
<ul class="indexlist">
<li><a href="#idx580" class="indexlink">modify for new DCBE macro option</a>
</li>
<li><a href="#idx545" class="indexlink">modify to support 31-bit UCB</a>
</li>
<li><a href="#idx572" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGGPRE00
<ul class="indexlist">
<li><a href="#idx578" class="indexlink">modify for new DCBE macro option</a>
</li>
<li><a href="#idx543" class="indexlink">modify to support 31-bit UCB</a>
</li>
<li><a href="#idx570" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGXMSGEX
<ul class="indexlist">
<li><a href="#idx616" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx776" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx107" class="indexlink">migrating</a>
</li>
<li>NSLCTRLO
<ul class="indexlist">
<li><a href="#idx604" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLEHDRI
<ul class="indexlist">
<li><a href="#idx594" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLEHDRO
<ul class="indexlist">
<li><a href="#idx598" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLETRLI
<ul class="indexlist">
<li><a href="#idx600" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLETRLO
<ul class="indexlist">
<li><a href="#idx602" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLOHDRI
<ul class="indexlist">
<li><a href="#idx592" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLOHDRO
<ul class="indexlist">
<li><a href="#idx596" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLREPOS
<ul class="indexlist">
<li><a href="#idx608" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx898" class="indexlink">SDSF</a>
</li>
</ul>
</li>
<li><a href="#idx227" class="indexlink">Exploitation Support feature, z/OS V1R4 z990</a>
</li>
<li><a href="#idx785" class="indexlink">extended mode, IP PrintWay migration from basic mode to</a>
</li>
</ul>
<strong><a name="IDX1_46" href="#IDX0_46">F</a></strong>
<ul class="indexlist">
<li>FACILITY class, RACF
<ul class="indexlist">
<li><a href="#idx115" class="indexlink">defining new profiles</a>
</li>
<li><a href="#idx507" class="indexlink">OCSF profiles</a>
</li>
</ul>
</li>
<li>fast replication
<ul class="indexlist">
<li><a href="#idx642" class="indexlink">using</a>
</li>
</ul>
</li>
<li>features, hardware
<ul class="indexlist">
<li><a href="#idx181" class="indexlink">software support of z10</a>
</li>
<li><a href="#idx203" class="indexlink">software support of z9</a>
</li>
<li><a href="#idx224" class="indexlink">software support of z990</a>
</li>
</ul>
</li>
<li><a href="#idx33" class="indexlink">FFST, no migration actions for</a>
</li>
<li><a href="#idx428" class="indexlink">filtering, IP policy</a>
</li>
<li><a href="#idx409" class="indexlink">FIPS mode</a>
</li>
<li>first IPL, migration actions after
<ul class="indexlist">
<li><a href="#idx376" class="indexlink">BCP</a>
</li>
<li><a href="#idx480" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx518" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx697" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx723" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx758" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx789" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx798" class="indexlink">ISPF</a>
</li>
<li><a href="#idx809" class="indexlink">JES2</a>
</li>
<li><a href="#idx858" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx883" class="indexlink">RMF</a>
</li>
<li><a href="#idx904" class="indexlink">SDSF</a>
</li>
<li><a href="#idx953" class="indexlink">Security Server</a>
</li>
<li><a href="#idx282" class="indexlink">sysplex</a>
</li>
<li><a href="#idx988" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1002" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1034" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>first IPL, migration actions before
<ul class="indexlist">
<li><a href="#idx310" class="indexlink">BCP</a>
</li>
<li><a href="#idx455" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx496" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx559" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx717" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx750" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx90" class="indexlink">general</a>
</li>
<li><a href="#idx772" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx824" class="indexlink">JES3</a>
</li>
<li><a href="#idx837" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx867" class="indexlink">Library Server</a>
</li>
<li><a href="#idx875" class="indexlink">RMF</a>
</li>
<li><a href="#idx895" class="indexlink">SDSF</a>
</li>
<li><a href="#idx938" class="indexlink">Security Server</a>
</li>
<li><a href="#idx275" class="indexlink">sysplex</a>
</li>
<li><a href="#idx982" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1026" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>Fix Category
<a href="#idx157" class="indexlink">(1)</a>, <a href="#idx173" class="indexlink">(2)</a>
</li>
<li>FIXCAT
<a href="#idx16" class="indexlink">(1)</a>, <a href="#idx156" class="indexlink">(2)</a>, <a href="#idx172" class="indexlink">(3)</a>
</li>
<li><a href="#idx321" class="indexlink">Flash Express</a>
</li>
<li>FlashCopy
<ul class="indexlist">
<li><a href="#idx641" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li><a href="#idx429" class="indexlink">fragments, filtering</a>
</li>
<li><a href="#idx643" class="indexlink">FRRECOV</a>
</li>
<li><a href="#idx421" class="indexlink">FTCHKPWD exit routine</a>
</li>
<li>FTP
<ul class="indexlist">
<li><a href="#idx402" class="indexlink">FTP daemon console messages</a>
</li>
</ul>
</li>
<li><a href="#idx401" class="indexlink">FTP daemon console messages</a>
</li>
<li><a href="#idx420" class="indexlink">FTP user exit routine FTCHKPWD</a>
</li>
</ul>
<strong><a name="IDX1_47" href="#IDX0_47">G</a></strong>
<ul class="indexlist">
<li><a href="#idx34" class="indexlink">GDDM, no migration actions for</a>
</li>
<li><a href="#idx35" class="indexlink">GDDM-PGF, no migration actions for</a>
</li>
<li><a href="#idx36" class="indexlink">GDDM-REXX, no migration actions for</a>
</li>
<li>general migration actions
<ul class="indexlist">
<li><a href="#idx86" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx54" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx439" class="indexlink">getaddrinfo()</a>
</li>
<li><a href="#idx380" class="indexlink">GRS</a>
<ul class="indexlist">
<li><a href="#idx382" class="indexlink">GRSCNFxx parmlib member</a>
</li>
</ul>
</li>
<li>GRSCNFxx parmlib member
<ul class="indexlist">
<li><a href="#idx381" class="indexlink">AUTHQLVL parameter</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_48" href="#IDX0_48">H</a></strong>
<ul class="indexlist">
<li><a href="#idx391" class="indexlink">Hardware Instrumentation Services (HIS)</a>
</li>
<li><a href="#idx137" class="indexlink">hardware migration actions</a>
</li>
<li><a href="#idx37" class="indexlink">HCD, no migration actions for</a>
</li>
<li><a href="#idx38" class="indexlink">HCM, no migration actions for</a>
</li>
<li><a href="#idx12" class="indexlink">health checks, migration</a>
</li>
<li><a href="#idx127" class="indexlink">health checks, updating</a>
</li>
<li><a href="#idx1020" class="indexlink">HFS to zFS, migrating file system from</a>
</li>
<li><a href="#idx191" class="indexlink">HiperDispatch</a>
</li>
<li><a href="#idx336" class="indexlink">HIPERDISPATCH=YES, default</a>
</li>
<li><a href="#idx392" class="indexlink">HIS (Hardware Instrumentation Services)</a>
</li>
<li><a href="#idx39" class="indexlink">HLASM, no migration actions for</a>
</li>
<li><a href="#idx40" class="indexlink">HLASM Toolkit, no migration actions for</a>
</li>
<li><a href="#idx229" class="indexlink">HMC microcode, upgrading</a>
</li>
<li>HOLDDATA
<a href="#idx158" class="indexlink">(1)</a>, <a href="#idx174" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_49" href="#IDX0_49">I</a></strong>
<ul class="indexlist">
<li><a href="#idx41" class="indexlink">IBM HTTP Server, no migration actions for</a>
</li>
<li><a href="#idx18" class="indexlink">IBM z/OS Management Facility</a>
</li>
<li><a href="#idx42" class="indexlink">ICKDSF, no migration actions for</a>
</li>
<li><a href="#idx1" class="indexlink">IClassifyBy migrating_def.dita</a>
</li>
<li><a href="#idx410" class="indexlink">ICSF</a>
</li>
<li><a href="#idx500" class="indexlink">ICSF, ensuring that the CSFPUTIL utility is not used to initialize a PKDS</a>
</li>
<li><a href="#idx521" class="indexlink">ICSF master keys</a>
</li>
<li><a href="#idx499" class="indexlink">ICSF migration action</a>
</li>
<li><a href="#idx487" class="indexlink">ICSF migration actions</a>
</li>
<li><a href="#idx502" class="indexlink">ICSF startup procedure, modifying</a>
</li>
<li>identity propagation
<a href="#idx933" class="indexlink">(1)</a>, <a href="#idx948" class="indexlink">(2)</a>, <a href="#idx961" class="indexlink">(3)</a>
</li>
<li>IEAOPTxx keyword
<ul class="indexlist">
<li><a href="#idx337" class="indexlink">HIPERDISPATCH=YES, default</a>
</li>
</ul>
</li>
<li>IEASYSxx
<ul class="indexlist">
<li><a href="#idx293" class="indexlink">WARNUND</a>
</li>
</ul>
</li>
<li><a href="#idx575" class="indexlink">IEBCOPY update</a>
</li>
<li>IEEVARYD
<ul class="indexlist">
<li><a href="#idx569" class="indexlink">DFSMSdss</a>
</li>
</ul>
</li>
<li>IFASMFDL
<a href="#idx354" class="indexlink">(1)</a>, <a href="#idx356" class="indexlink">(2)</a>
</li>
<li>IFASMFDP
<a href="#idx355" class="indexlink">(1)</a>, <a href="#idx357" class="indexlink">(2)</a>
</li>
<li><a href="#idx555" class="indexlink">IGGCATxx</a>
</li>
<li><a href="#idx408" class="indexlink">IKE daemon</a>
</li>
<li><a href="#idx548" class="indexlink">IMBED attribute for VSAM data sets, removal of</a>
</li>
<li><a href="#idx890" class="indexlink">IN-READY QUEUE</a>
</li>
<li><a href="#idx766" class="indexlink">Increasing space for Printer Inventory</a>
</li>
<li><a href="#idx194" class="indexlink">InfiniBand</a>
</li>
<li><a href="#idx779" class="indexlink">Infoprint Server</a>
</li>
<li>Infoprint Server migration actions
<ul class="indexlist">
<li><a href="#idx786" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx769" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx762" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx914" class="indexlink">initiators on the SDSF INIT panel</a>
</li>
<li><a href="#idx8" class="indexlink">installation steps</a>
</li>
<li>installing, migration actions before
<ul class="indexlist">
<li><a href="#idx765" class="indexlink">Infoprint Server</a>
</li>
</ul>
</li>
<li><a href="#idx43" class="indexlink">Integrated Security Services, no migration actions for</a>
</li>
<li><a href="#idx535" class="indexlink">integrity of SMS control data sets</a>
</li>
<li>Internet address
<ul class="indexlist">
<li><a href="#idx504" class="indexlink">for ABENDDC2-16 in CSFKSTDC</a>
</li>
<li><a href="#idx261" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="#idx258" class="indexlink">for CFSizer tool</a>
</li>
<li>for Enhanced PSP Tool
<a href="#idx187" class="indexlink">(1)</a>, <a href="#idx209" class="indexlink">(2)</a>, <a href="#idx231" class="indexlink">(3)</a>
</li>
<li>for flashes
<a href="#idx120" class="indexlink">(1)</a>, <a href="#idx125" class="indexlink">(2)</a>
</li>
<li><a href="#idx111" class="indexlink">for ISVs</a>
</li>
<li><a href="#idx62" class="indexlink">for PSP buckets</a>
</li>
<li><a href="#idx77" class="indexlink">for redbooks</a>
</li>
<li><a href="#idx234" class="indexlink">for Resource Link</a>
</li>
<li><a href="#idx71" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li><a href="#idx414" class="indexlink">Intrusion Detection Services and traffic monitoring</a>
</li>
<li><a href="#idx1037" class="indexlink">invalid REXX variables</a>
</li>
<li><a href="#idx737" class="indexlink">IOEFSPRM</a>
</li>
<li><a href="#idx425" class="indexlink">IP filter policy</a>
</li>
<li><a href="#idx783" class="indexlink">IP PrintWay migration from basic mode to extended mode</a>
</li>
<li><a href="#idx462" class="indexlink">IP validation checks</a>
</li>
<li><a href="#idx1005" class="indexlink">IPA option changes</a>
</li>
<li><a href="#idx93" class="indexlink">IPCS, setting up</a>
</li>
<li><a href="#idx427" class="indexlink">IpFilterPolicy statement</a>
</li>
<li>IPL, migration actions after first
<ul class="indexlist">
<li><a href="#idx377" class="indexlink">BCP</a>
</li>
<li><a href="#idx481" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx519" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx698" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx724" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx759" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx790" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx799" class="indexlink">ISPF</a>
</li>
<li><a href="#idx810" class="indexlink">JES2</a>
</li>
<li><a href="#idx859" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx884" class="indexlink">RMF</a>
</li>
<li><a href="#idx905" class="indexlink">SDSF</a>
</li>
<li><a href="#idx954" class="indexlink">Security Server</a>
</li>
<li><a href="#idx283" class="indexlink">sysplex</a>
</li>
<li><a href="#idx989" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1003" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1035" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>IPL, migration actions before first
<ul class="indexlist">
<li><a href="#idx311" class="indexlink">BCP</a>
</li>
<li><a href="#idx456" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx497" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx560" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx718" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx751" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx91" class="indexlink">general</a>
</li>
<li><a href="#idx773" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx825" class="indexlink">JES3</a>
</li>
<li><a href="#idx838" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx868" class="indexlink">Library Server</a>
</li>
<li><a href="#idx876" class="indexlink">RMF</a>
</li>
<li><a href="#idx896" class="indexlink">SDSF</a>
</li>
<li><a href="#idx939" class="indexlink">Security Server</a>
</li>
<li><a href="#idx276" class="indexlink">sysplex</a>
</li>
<li><a href="#idx983" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1027" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx313" class="indexlink">IPL text, creating</a>
</li>
<li><a href="#idx484" class="indexlink">IPv6 router advertisement messages</a>
</li>
<li><a href="#idx342" class="indexlink">IRARASD macro, recompile module which includes</a>
</li>
<li><a href="#idx959" class="indexlink">IRRMIN00 utility, RACF</a>
</li>
<li>ISF770W
<a href="#idx922" class="indexlink">(1)</a>, <a href="#idx924" class="indexlink">(2)</a>
</li>
<li>ISFPARMS
<a href="#idx913" class="indexlink">(1)</a>, <a href="#idx917" class="indexlink">(2)</a>, <a href="#idx921" class="indexlink">(3)</a>
</li>
<li>ISFPARMS, SDSF
<ul class="indexlist">
<li><a href="#idx900" class="indexlink">reassembling</a>
</li>
</ul>
</li>
<li>ISPF migration actions
<ul class="indexlist">
<li><a href="#idx795" class="indexlink">after first IPL</a>
</li>
</ul>
</li>
<li><a href="#idx109" class="indexlink">ISV products, reconnecting</a>
</li>
<li><a href="#idx446" class="indexlink">IVTCSM ASSIGN_BUFFER requests</a>
</li>
</ul>
<strong><a name="IDX1_4A" href="#IDX0_4A">J</a></strong>
<ul class="indexlist">
<li>JES2
<ul class="indexlist">
<li><a href="#idx812" class="indexlink">z11 mode</a>
</li>
</ul>
</li>
<li>JES2 migration actions
<ul class="indexlist">
<li><a href="#idx806" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx802" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx819" class="indexlink">JES3 DLOG</a>
</li>
<li><a href="#idx832" class="indexlink">JES3 migration actions</a>
<ul class="indexlist">
<li><a href="#idx821" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx815" class="indexlink">before installing</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_4B" href="#IDX0_4B">K</a></strong>
<ul class="indexlist">
<li><a href="#idx465" class="indexlink">key exchange policy rules for a dynamic VPN</a>
</li>
<li><a href="#idx550" class="indexlink">KEYRANGE attribute for VSAM data sets, removal of</a>
</li>
</ul>
<strong><a name="IDX1_4C" href="#IDX0_4C">L</a></strong>
<ul class="indexlist">
<li><a href="#idx852" class="indexlink">Language Environment</a>
</li>
<li>Language Environment migration actions
<ul class="indexlist">
<li><a href="#idx855" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx834" class="indexlink">before first IPL</a>
</li>
</ul>
</li>
<li><a href="#idx193" class="indexlink">large page support</a>
</li>
<li><a href="#idx363" class="indexlink">LCCA</a>
</li>
<li>library lookaside (LLA)
<ul class="indexlist">
<li><a href="#idx328" class="indexlink">restart</a>
</li>
</ul>
</li>
<li>Library Server migration actions
<ul class="indexlist">
<li><a href="#idx864" class="indexlink">before first IPL</a>
</li>
</ul>
</li>
<li>link pack area (LPA)
<ul class="indexlist">
<li><a href="#idx845" class="indexlink">Language Environment load modules in</a>
</li>
<li><a href="#idx252" class="indexlink">relieving virtual storage constraint with</a>
</li>
</ul>
</li>
<li><a href="#idx688" class="indexlink">LIST command</a>
</li>
<li>LISTCAT
<ul class="indexlist">
<li>removal of NOIMBED and NOREPLICAT from output
<ul class="indexlist">
<li><a href="#idx542" class="indexlink">migration action for</a>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#idx371" class="indexlink">LOGRECSUMMARY statement value in CEAPRMxx</a>
</li>
<li>LPA (link pack area)
<ul class="indexlist">
<li><a href="#idx846" class="indexlink">Language Environment load modules in</a>
</li>
<li><a href="#idx253" class="indexlink">relieving virtual storage constraint with</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_4D" href="#IDX0_4D">M</a></strong>
<ul class="indexlist">
<li><a href="#idx64" class="indexlink">maintenance, coexistence and fallback</a>
</li>
<li><a href="#idx525" class="indexlink">maintenance task for PKI Services</a>
</li>
<li>Managed System Infrastructure for Setup (msys for Setup)
<ul class="indexlist">
<li><a href="#idx84" class="indexlink">withdrawal</a>
</li>
</ul>
</li>
<li><a href="#idx19" class="indexlink">Management Facility, IBM z/OS</a>
</li>
<li><a href="#idx522" class="indexlink">master keys, ICSF</a>
</li>
<li>MAXSOCKETS statement
<ul class="indexlist">
<li><a href="#idx1015" class="indexlink">support deleted from AF_UNIX</a>
</li>
</ul>
</li>
<li>MEMLIMIT parameter
<ul class="indexlist">
<li><a href="#idx118" class="indexlink">determining virtual storage with</a>
</li>
</ul>
</li>
<li><a href="#idx320" class="indexlink">memory pool</a>
</li>
<li><a href="#idx470" class="indexlink">message catalogs</a>
</li>
<li>messages
<ul class="indexlist">
<li><a href="#idx649" class="indexlink">ARC1809I</a>
</li>
<li><a href="#idx681" class="indexlink">ARC1820I</a>
</li>
<li><a href="#idx326" class="indexlink">XCF/XES</a>
</li>
</ul>
</li>
<li>Messages
<ul class="indexlist">
<li><a href="#idx831" class="indexlink">IAT3100</a>
</li>
</ul>
</li>
<li><a href="#idx661" class="indexlink">messages, changed type</a>
</li>
<li>messages, updating automation for changed
<a href="#idx102" class="indexlink">(1)</a>, <a href="#idx650" class="indexlink">(2)</a>, <a href="#idx660" class="indexlink">(3)</a>
</li>
<li><a href="#idx44" class="indexlink">Metal C Runtime Library, no migration actions for</a>
</li>
<li><a href="#idx432" class="indexlink">MIB object, SNMP sysObjectID</a>
</li>
<li><a href="#idx45" class="indexlink">MICR/OCR, no migration actions for</a>
</li>
<li>migration actions
<ul class="indexlist">
<li>after first IPL
<ul class="indexlist">
<li><a href="#idx374" class="indexlink">BCP</a>
</li>
<li><a href="#idx478" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx516" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx695" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx721" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx756" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx787" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx796" class="indexlink">ISPF</a>
</li>
<li><a href="#idx807" class="indexlink">JES2</a>
</li>
<li><a href="#idx856" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx881" class="indexlink">RMF</a>
</li>
<li><a href="#idx902" class="indexlink">SDSF</a>
</li>
<li><a href="#idx951" class="indexlink">Security Server</a>
</li>
<li><a href="#idx280" class="indexlink">sysplex</a>
</li>
<li><a href="#idx986" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1000" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1032" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx285" class="indexlink">BCP</a>
</li>
<li>before first IPL
<ul class="indexlist">
<li><a href="#idx308" class="indexlink">BCP</a>
</li>
<li><a href="#idx453" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx494" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx557" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx715" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx748" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx87" class="indexlink">general</a>
</li>
<li><a href="#idx770" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx822" class="indexlink">JES3</a>
</li>
<li><a href="#idx835" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx865" class="indexlink">Library Server</a>
</li>
<li><a href="#idx873" class="indexlink">RMF</a>
</li>
<li><a href="#idx893" class="indexlink">SDSF</a>
</li>
<li><a href="#idx936" class="indexlink">Security Server</a>
</li>
<li><a href="#idx273" class="indexlink">sysplex</a>
</li>
<li><a href="#idx980" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1024" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>before installing
<ul class="indexlist">
<li><a href="#idx287" class="indexlink">BCP</a>
</li>
<li><a href="#idx397" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx490" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx529" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx733" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx56" class="indexlink">general</a>
</li>
<li><a href="#idx763" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx803" class="indexlink">JES2</a>
</li>
<li><a href="#idx816" class="indexlink">JES3</a>
</li>
<li><a href="#idx928" class="indexlink">Security Server</a>
</li>
<li><a href="#idx268" class="indexlink">sysplex</a>
</li>
<li><a href="#idx974" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx996" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1008" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx993" class="indexlink">C/C++</a>
</li>
<li><a href="#idx395" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx486" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx527" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx713" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx731" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx53" class="indexlink">for everyone</a>
</li>
<li><a href="#idx52" class="indexlink">general</a>
</li>
<li><a href="#idx138" class="indexlink">hardware</a>
</li>
<li><a href="#idx761" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx794" class="indexlink">ISPF</a>
</li>
<li><a href="#idx801" class="indexlink">JES2</a>
</li>
<li><a href="#idx814" class="indexlink">JES3</a>
</li>
<li><a href="#idx833" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx863" class="indexlink">Library Server</a>
</li>
<li><a href="#idx22" class="indexlink">none, elements and features with</a>
</li>
<li><a href="#idx871" class="indexlink">RMF</a>
</li>
<li><a href="#idx891" class="indexlink">SDSF</a>
</li>
<li><a href="#idx926" class="indexlink">Security Server</a>
</li>
<li><a href="#idx966" class="indexlink">SMP/E</a>
<ul class="indexlist">
<li><a href="#idx968" class="indexlink">after installing but before using</a>
</li>
</ul>
</li>
<li><a href="#idx265" class="indexlink">sysplex</a>
</li>
<li><a href="#idx972" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx994" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1006" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx11" class="indexlink">migration health checks</a>
</li>
<li><a href="#idx5" class="indexlink">migration paths supported</a>
</li>
<li><a href="#idx9" class="indexlink">migration steps</a>
</li>
<li>modifications, user
<ul class="indexlist">
<li><a href="#idx104" class="indexlink">examining</a>
</li>
<li><a href="#idx848" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
<li><a href="#idx501" class="indexlink">Modify ICSF startup procedure</a>
</li>
<li><a href="#idx886" class="indexlink">Monitor III version, using correct</a>
</li>
<li><a href="#idx727" class="indexlink">MOWRK, DFSORT</a>
</li>
<li>MTFTPS
<ul class="indexlist">
<li><a href="#idx322" class="indexlink">discontinue use</a>
</li>
</ul>
</li>
<li><a href="#idx443" class="indexlink">multi-thread tasks</a>
</li>
<li><a href="#idx670" class="indexlink">Multicluster CDS</a>
</li>
<li><a href="#idx476" class="indexlink">MULTPATH=TCPVALUE start option</a>
</li>
<li><a href="#idx393" class="indexlink">MVS_Binder</a>
</li>
<li><a href="#idx667" class="indexlink">MVT (SMS) chain rebuild (DFSMShsm), removal of patch preventing</a>
</li>
</ul>
<strong><a name="IDX1_4E" href="#IDX0_4E">N</a></strong>
<ul class="indexlist">
<li><a href="#idx461" class="indexlink">name server responsiveness, resolver monitoring of</a>
</li>
<li><a href="#idx469" class="indexlink">Netstat message catalogs and timestamps</a>
</li>
<li><a href="#idx132" class="indexlink">new data sets</a>
</li>
<li><a href="#idx46" class="indexlink">NFS, no migration actions for</a>
</li>
<li>normalization of RACF user names
<a href="#idx934" class="indexlink">(1)</a>, <a href="#idx949" class="indexlink">(2)</a>, <a href="#idx962" class="indexlink">(3)</a>
</li>
<li><a href="#idx870" class="indexlink">notes files, Library Server</a>
</li>
</ul>
<strong><a name="IDX1_4F" href="#IDX0_4F">O</a></strong>
<ul class="indexlist">
<li><a href="#idx704" class="indexlink">OAM DB2 BIND jobs</a>
</li>
<li><a href="#idx506" class="indexlink">OCSF directory migration</a>
</li>
<li><a href="#idx488" class="indexlink">OCSF migration actions</a>
</li>
<li><a href="#idx317" class="indexlink">one-stage JCL</a>
</li>
<li><a href="#idx316" class="indexlink">one-step JCL</a>
</li>
<li><a href="#idx332" class="indexlink">OPERLOG EMCS console name change</a>
</li>
<li><a href="#idx909" class="indexlink">OPERLOG panel</a>
</li>
<li><a href="#idx841" class="indexlink">options, Language Environment changes to runtime</a>
</li>
<li><a href="#idx433" class="indexlink">OSNMPD.DATA file, SNMP sysObjectID MIB object in</a>
</li>
<li>output changes
<a href="#idx684" class="indexlink">(1)</a>, <a href="#idx689" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_50" href="#IDX0_50">P</a></strong>
<ul class="indexlist">
<li><a href="#idx195" class="indexlink">Parallel Sysplex InfiniBand</a>
</li>
<li>Parallel Sysplex migration actions
<ul class="indexlist">
<li><a href="#idx279" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx272" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx267" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>parmlib
<ul class="indexlist">
<li><a href="#idx247" class="indexlink">CSFIPCSP new member for ICSF</a>
</li>
<li><a href="#idx94" class="indexlink">used by IPCS</a>
</li>
<li><a href="#idx96" class="indexlink">using shipped members of</a>
</li>
</ul>
</li>
<li><a href="#idx362" class="indexlink">parmlib DIAGxx</a>
</li>
<li><a href="#idx423" class="indexlink">password or password phrase</a>
</li>
<li><a href="#idx651" class="indexlink">patch disabling unwanted ARC1809I messages (DFSMShsm), removal of</a>
</li>
<li><a href="#idx664" class="indexlink">patch preventing the SMS MVT chain rebuild (DFSMShsm), removal of</a>
</li>
<li><a href="#idx131" class="indexlink">paths, deleted</a>
</li>
<li><a href="#idx6" class="indexlink">paths supported, migration</a>
</li>
<li><a href="#idx364" class="indexlink">PCCA</a>
</li>
<li>PDA trace
<ul class="indexlist">
<li><a href="#idx634" class="indexlink">at startup, DFSMShsm</a>
</li>
<li><a href="#idx635" class="indexlink">default change</a>
</li>
</ul>
</li>
<li><a href="#idx134" class="indexlink">PDSE sharing restrictions</a>
</li>
<li><a href="#idx394" class="indexlink">PFA</a>
</li>
<li>PFA (Predictive Failure Analysis)
<ul class="indexlist">
<li><a href="#idx359" class="indexlink">directory setting</a>
</li>
</ul>
</li>
<li><a href="#idx303" class="indexlink">PGSER</a>
</li>
<li><a href="#idx509" class="indexlink">PKCS #11 token certificate chains</a>
</li>
<li><a href="#idx508" class="indexlink">PKCS #11 tokens</a>
</li>
<li><a href="#idx523" class="indexlink">PKI Services, daily maintenance task</a>
</li>
<li><a href="#idx466" class="indexlink">policy rules for a dynamic VPN, defining key exchange</a>
</li>
<li>post-IPL migration actions
<ul class="indexlist">
<li><a href="#idx482" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx520" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx699" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx725" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx760" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx791" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx800" class="indexlink">ISPF</a>
</li>
<li><a href="#idx811" class="indexlink">JES2</a>
</li>
<li><a href="#idx860" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx885" class="indexlink">RMF</a>
</li>
<li><a href="#idx906" class="indexlink">SDSF</a>
</li>
<li><a href="#idx955" class="indexlink">Security Server</a>
</li>
<li><a href="#idx284" class="indexlink">sysplex</a>
</li>
<li><a href="#idx990" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1004" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1036" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>pre-IPL migration actions
<ul class="indexlist">
<li><a href="#idx312" class="indexlink">BCP</a>
</li>
<li><a href="#idx457" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx498" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx561" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx719" class="indexlink">DFSORT</a>
</li>
<li><a href="#idx752" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx92" class="indexlink">general</a>
</li>
<li><a href="#idx774" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx826" class="indexlink">JES3</a>
</li>
<li><a href="#idx839" class="indexlink">Language Environment</a>
</li>
<li><a href="#idx869" class="indexlink">Library Server</a>
</li>
<li><a href="#idx877" class="indexlink">RMF</a>
</li>
<li><a href="#idx897" class="indexlink">SDSF</a>
</li>
<li><a href="#idx940" class="indexlink">Security Server</a>
</li>
<li><a href="#idx277" class="indexlink">sysplex</a>
</li>
<li><a href="#idx984" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx1028" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li>Predictive Failure Analysis (PFA)
<ul class="indexlist">
<li><a href="#idx294" class="indexlink">DASD</a>
</li>
<li><a href="#idx358" class="indexlink">directory setting</a>
</li>
<li><a href="#idx295" class="indexlink">storage requirements</a>
</li>
</ul>
</li>
<li>preinstallation migration actions
<ul class="indexlist">
<li><a href="#idx289" class="indexlink">BCP</a>
</li>
<li><a href="#idx399" class="indexlink">Communications Server</a>
</li>
<li><a href="#idx492" class="indexlink">Cryptographic Services</a>
</li>
<li><a href="#idx531" class="indexlink">DFSMS</a>
</li>
<li><a href="#idx735" class="indexlink">Distributed File Service</a>
</li>
<li><a href="#idx58" class="indexlink">general</a>
</li>
<li>JES
<a href="#idx805" class="indexlink">(1)</a>, <a href="#idx818" class="indexlink">(2)</a>
</li>
<li><a href="#idx930" class="indexlink">Security Server</a>
</li>
<li><a href="#idx270" class="indexlink">sysplex</a>
</li>
<li><a href="#idx976" class="indexlink">TSO/E</a>
</li>
<li><a href="#idx998" class="indexlink">XL C/C++</a>
</li>
<li><a href="#idx1010" class="indexlink">z/OS UNIX</a>
</li>
</ul>
</li>
<li><a href="#idx665" class="indexlink">preventing the SMS MVT chain rebuild (DFSMShsm), removal of patch</a>
</li>
<li><a href="#idx775" class="indexlink">printer inventory, migrating</a>
</li>
<li><a href="#idx345" class="indexlink">problem determination and console commands</a>
</li>
<li>problem documentation upload utility (PDUU)
<ul class="indexlist">
<li><a href="#idx323" class="indexlink">support for</a>
</li>
</ul>
</li>
<li>problem management
<ul class="indexlist">
<li><a href="#idx387" class="indexlink">PFA</a>
</li>
<li><a href="#idx341" class="indexlink">Runtime Diagnostics</a>
</li>
<li><a href="#idx386" class="indexlink">Runtime Diagnostics and PFA</a>
</li>
</ul>
</li>
<li><a href="#idx114" class="indexlink">procedures, updating operational</a>
</li>
<li>Process Manager
<ul class="indexlist">
<li><a href="#idx1017" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li>processors
<ul class="indexlist">
<li><a href="#idx180" class="indexlink">migrating to z10</a>
</li>
<li>migrating to z114
<a href="#idx152" class="indexlink">(1)</a>, <a href="#idx168" class="indexlink">(2)</a>
</li>
<li>migrating to z196
<a href="#idx147" class="indexlink">(1)</a>, <a href="#idx163" class="indexlink">(2)</a>
</li>
<li><a href="#idx217" class="indexlink">migrating to z890</a>
</li>
<li><a href="#idx202" class="indexlink">migrating to z9</a>
</li>
<li><a href="#idx213" class="indexlink">migrating to z990</a>
</li>
<li>migrating to zEC12
<a href="#idx143" class="indexlink">(1)</a>, <a href="#idx159" class="indexlink">(2)</a>
</li>
<li><a href="#idx242" class="indexlink">z890 coexistence requirements</a>
</li>
<li><a href="#idx238" class="indexlink">z990 coexistence requirements</a>
</li>
</ul>
</li>
<li><a href="#idx98" class="indexlink">proclib, using shipped members of</a>
</li>
<li><a href="#idx75" class="indexlink">Products depending on DCE technologies</a>
</li>
<li><a href="#idx378" class="indexlink">Provisioning Manager</a>
</li>
<li><a href="#idx196" class="indexlink">PSIFB (Parallel Sysplex InfiniBand)</a>
</li>
<li>PSP bucket
<ul class="indexlist">
<li><a href="#idx59" class="indexlink">reviewing</a>
</li>
<li><a href="#idx60" class="indexlink">upgrade IDs</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_51" href="#IDX0_51">Q</a></strong>
<ul class="indexlist">
<li><a href="#idx404" class="indexlink">QDIO inbound workload queueing for EE traffic</a>
</li>
<li><a href="#idx383" class="indexlink">qnames</a>
</li>
<li><a href="#idx683" class="indexlink">QUERY command</a>
</li>
</ul>
<strong><a name="IDX1_52" href="#IDX0_52">R</a></strong>
<ul class="indexlist">
<li>RACDCERT GENCERT and REKEY defaults
<ul class="indexlist">
<li>RACDCERT GENCERT
<ul class="indexlist">
<li><a href="#idx963" class="indexlink">REKEY</a>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#idx958" class="indexlink">RACF database templates, updating</a>
</li>
<li>RACF migration actions
<ul class="indexlist">
<li><a href="#idx956" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx941" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx931" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx448" class="indexlink">reason code 26</a>
</li>
<li><a href="#idx669" class="indexlink">rebuild of chain (DFSMShsm), removal of patch preventing SMS MVT</a>
</li>
<li>Redbooks
<ul class="indexlist">
<li><a href="#idx79" class="indexlink">URL</a>
</li>
</ul>
</li>
<li><a href="#idx779" class="indexlink">region size change</a>
</li>
<li><a href="#idx778" class="indexlink">region size change, Infoprint Server</a>
</li>
<li><a href="#idx4" class="indexlink">releases supported for migration</a>
</li>
<li><a href="#idx663" class="indexlink">Removal of the patch preventing the SMS MVT chain rebuild (DFSMShsm)</a>
</li>
<li><a href="#idx129" class="indexlink">removed data sets and paths</a>
</li>
<li><a href="#idx793" class="indexlink">Removing Version 1 Printer Inventory</a>
</li>
<li><a href="#idx767" class="indexlink">Removing Version 2 Printer Inventory</a>
</li>
<li><a href="#idx549" class="indexlink">REPLICATE attribute for VSAM data sets, removal of</a>
</li>
<li><a href="#idx17" class="indexlink">REPORT MISSINGFIX</a>
</li>
<li><a href="#idx441" class="indexlink">resolver and addrinfo storage</a>
</li>
<li><a href="#idx460" class="indexlink">resolver monitoring of name server responsiveness</a>
</li>
<li><a href="#idx434" class="indexlink">resolver UDP request timeout interval duration</a>
</li>
<li><a href="#idx632" class="indexlink">RESTORE</a>
</li>
<li>REUSASID
<ul class="indexlist">
<li><a href="#idx368" class="indexlink">default changes</a>
</li>
</ul>
</li>
<li><a href="#idx426" class="indexlink">RFC 4301</a>
</li>
<li><a href="#idx440" class="indexlink">RFC 5014</a>
</li>
<li>RMF
<ul class="indexlist">
<li><a href="#idx889" class="indexlink">IN-READY QUEUE</a>
</li>
<li><a href="#idx888" class="indexlink">SMF 72.5 data collection</a>
</li>
</ul>
</li>
<li>RMF migration actions
<ul class="indexlist">
<li><a href="#idx880" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx872" class="indexlink">before first IPL</a>
</li>
</ul>
</li>
<li><a href="#idx81" class="indexlink">root size, z/OS</a>
</li>
<li><a href="#idx485" class="indexlink">router advertisement messages</a>
</li>
<li><a href="#idx944" class="indexlink">router table, RACF</a>
</li>
<li><a href="#idx305" class="indexlink">RTLS</a>
</li>
<li><a href="#idx47" class="indexlink">Run-Time Library Extensions, no migration actions for</a>
</li>
<li>Runtime Diagnostics
<a href="#idx338" class="indexlink">(1)</a>, <a href="#idx339" class="indexlink">(2)</a>
<ul class="indexlist">
<li>HZR address space
<a href="#idx340" class="indexlink">(1)</a>, <a href="#idx385" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="#idx840" class="indexlink">runtime options, Language Environment changes to</a>
</li>
<li><a href="#idx851" class="indexlink">runtime options report</a>
</li>
</ul>
<strong><a name="IDX1_53" href="#IDX0_53">S</a></strong>
<ul class="indexlist">
<li><a href="#idx417" class="indexlink">scan detection</a>
</li>
<li><a href="#idx537" class="indexlink">SCDS (source control data set), ensuring integrity of</a>
</li>
<li>SDSF custom properties
<a href="#idx912" class="indexlink">(1)</a>, <a href="#idx916" class="indexlink">(2)</a>, <a href="#idx920" class="indexlink">(3)</a>
</li>
<li>SDSF message ISF770W
<a href="#idx923" class="indexlink">(1)</a>, <a href="#idx925" class="indexlink">(2)</a>
</li>
<li>SDSF migration actions
<ul class="indexlist">
<li><a href="#idx901" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx892" class="indexlink">before first IPL</a>
</li>
</ul>
</li>
<li><a href="#idx971" class="indexlink">security</a>
</li>
<li><a href="#idx463" class="indexlink">security key exchanges</a>
</li>
<li>Security Server migration actions
<ul class="indexlist">
<li><a href="#idx950" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx935" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx927" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx679" class="indexlink">security system</a>
</li>
<li>server, z10
<ul class="indexlist">
<li><a href="#idx184" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx178" class="indexlink">migrating to</a>
</li>
<li><a href="#idx179" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>server, z114
<ul class="indexlist">
<li>software support features
<a href="#idx154" class="indexlink">(1)</a>, <a href="#idx170" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>server, z196
<ul class="indexlist">
<li>software support features
<a href="#idx149" class="indexlink">(1)</a>, <a href="#idx165" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>server, z890
<ul class="indexlist">
<li><a href="#idx241" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx216" class="indexlink">migrating to</a>
</li>
<li><a href="#idx223" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>server, z9
<ul class="indexlist">
<li><a href="#idx206" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx200" class="indexlink">migrating to</a>
</li>
<li><a href="#idx201" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>server, z990
<ul class="indexlist">
<li><a href="#idx237" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx212" class="indexlink">migrating to</a>
</li>
<li><a href="#idx221" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>server, zEC12
<ul class="indexlist">
<li><a href="#idx141" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li><a href="#idx263" class="indexlink">Server Time Protocol (STP) feature</a>
</li>
<li>SETSYS DSSXMMODE
<a href="#idx674" class="indexlink">(1)</a>, <a href="#idx678" class="indexlink">(2)</a>
</li>
<li>SETSYS FASTREPLICATION
<ul class="indexlist">
<li><a href="#idx644" class="indexlink">DATASETRECOVERY</a>
</li>
<li><a href="#idx652" class="indexlink">VOLUMEPAIRMESSAGES</a>
</li>
</ul>
</li>
<li><a href="#idx745" class="indexlink">shared file system</a>
</li>
<li><a href="#idx135" class="indexlink">sharing restrictions, PDSE</a>
</li>
<li>skulker shell command
<ul class="indexlist">
<li><a href="#idx1038" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li><a href="#idx887" class="indexlink">SMF 72.5 data collection</a>
</li>
<li><a href="#idx347" class="indexlink">SMF messages</a>
</li>
<li>SMF records
<ul class="indexlist">
<li><a href="#idx246" class="indexlink">migrating to z990 or z890</a>
</li>
</ul>
</li>
<li>SMP/E
<ul class="indexlist">
<li><a href="#idx969" class="indexlink">authorize commands</a>
</li>
<li><a href="#idx970" class="indexlink">SAF checks</a>
</li>
</ul>
</li>
<li><a href="#idx971" class="indexlink">SMP/E functions</a>
</li>
<li>SMP/E migration actions
<ul class="indexlist">
<li><a href="#idx967" class="indexlink">after installing but before using</a>
</li>
</ul>
</li>
<li>SMP/E REPORT MISSINGFIX
<ul class="indexlist">
<li>FIXCAT
<a href="#idx155" class="indexlink">(1)</a>, <a href="#idx171" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="#idx532" class="indexlink">SMS control data sets, migrating</a>
</li>
<li><a href="#idx666" class="indexlink">SMS MVT chain rebuild (DFSMShsm), removal of patch preventing</a>
</li>
<li><a href="#idx430" class="indexlink">SNMP sysObjectID MIB object</a>
</li>
<li>software support of servers
<ul class="indexlist">
<li><a href="#idx182" class="indexlink">z10</a>
</li>
<li><a href="#idx204" class="indexlink">z9</a>
</li>
<li><a href="#idx225" class="indexlink">z990 and z890</a>
</li>
</ul>
</li>
<li><a href="#idx536" class="indexlink">source control data set (SCDS), ensuring integrity of</a>
</li>
<li><a href="#idx510" class="indexlink">SSL V3 and TLS session renegotiation</a>
</li>
<li><a href="#idx314" class="indexlink">stand-alone dump, reassembling</a>
</li>
<li><a href="#idx291" class="indexlink">stand-alone dump data sets</a>
</li>
<li><a href="#idx568" class="indexlink">Stand-Alone Services, building core image of DFSMSdss</a>
</li>
<li><a href="#idx339" class="indexlink">start</a>
</li>
<li><a href="#idx10" class="indexlink">steps for migration</a>
</li>
<li>storage
<ul class="indexlist">
<li><a href="#idx123" class="indexlink">backing virtual</a>
</li>
<li><a href="#idx69" class="indexlink">evaluation with zSoftCap</a>
</li>
<li><a href="#idx117" class="indexlink">setting virtual limits</a>
</li>
</ul>
</li>
<li>storage requirements
<ul class="indexlist">
<li><a href="#idx296" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li><a href="#idx264" class="indexlink">STP (Server Time Protocol) feature</a>
</li>
<li><a href="#idx438" class="indexlink">struct addrinfo</a>
</li>
<li><a href="#idx113" class="indexlink">subsystems, reconnecting</a>
</li>
<li><a href="#idx2" class="indexlink">summary of changes to this document</a>
</li>
<li><a href="#idx106" class="indexlink">SVC routines, migrating</a>
</li>
<li><a href="#idx1030" class="indexlink">symbolic links for cron, mail, and uucp utilities</a>
</li>
<li><a href="#idx566" class="indexlink">SYS1.IMAGELIB</a>
</li>
<li>SYS1.PARMLIB
<ul class="indexlist">
<li><a href="#idx248" class="indexlink">CSFIPCSP new member for ICSF</a>
</li>
<li><a href="#idx95" class="indexlink">used by IPCS</a>
</li>
<li><a href="#idx97" class="indexlink">using shipped members of</a>
</li>
</ul>
</li>
<li><a href="#idx99" class="indexlink">SYS1.PROCLIB, using shipped members of</a>
</li>
<li><a href="#idx343" class="indexlink">SYSEVENT REQFASD, work area</a>
</li>
<li><a href="#idx444" class="indexlink">syslogd configuration</a>
</li>
<li><a href="#idx431" class="indexlink">sysObjectID MIB object, SNMP</a>
</li>
<li><a href="#idx744" class="indexlink">sysplex=filesys</a>
</li>
<li>sysplex migration actions
<ul class="indexlist">
<li><a href="#idx278" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx271" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx266" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="#idx1022" class="indexlink">sysplex root from HFS to zFS, migrating</a>
</li>
<li><a href="#idx908" class="indexlink">sysplex-wide data on SDSF panels</a>
</li>
<li><a href="#idx511" class="indexlink">System SSL, enabling SSL V3 and TLS session renegotiation</a>
</li>
<li><a href="#idx514" class="indexlink">System SSL, ensuring that all RACF user IDs can access the CSFIQA resource</a>
</li>
<li><a href="#idx513" class="indexlink">System SSL migration action</a>
</li>
</ul>
<strong><a name="IDX1_54" href="#IDX0_54">T</a></strong>
<ul class="indexlist">
<li><a href="#idx483" class="indexlink">TCP/IP preference values</a>
</li>
<li><a href="#idx451" class="indexlink">TCPIPDS1 and ISTITDS1 specification from dump commands, removal</a>
</li>
<li><a href="#idx436" class="indexlink">timeout interval duration</a>
</li>
<li><a href="#idx471" class="indexlink">timestamps of Netstat message catalogs</a>
</li>
<li><a href="#idx48" class="indexlink">TIOC, no migration actions for</a>
</li>
<li><a href="#idx459" class="indexlink">TN3270E Telnet server messages</a>
</li>
<li><a href="#idx473" class="indexlink">TRACE command</a>
</li>
<li><a href="#idx415" class="indexlink">traffic monitoring</a>
</li>
<li><a href="#idx978" class="indexlink">TSO/E</a>
</li>
<li>TSO/E migration actions
<ul class="indexlist">
<li><a href="#idx985" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx979" class="indexlink">before first IPL</a>
</li>
<li>before installing
<a href="#idx973" class="indexlink">(1)</a>, <a href="#idx977" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>tsocmd shell command
<ul class="indexlist">
<li><a href="#idx1014" class="indexlink">support added</a>
</li>
</ul>
</li>
<li><a href="#idx190" class="indexlink">TUNE(8) compiler option</a>
</li>
</ul>
<strong><a name="IDX1_55" href="#IDX0_55">U</a></strong>
<ul class="indexlist">
<li><a href="#idx435" class="indexlink">UDP request timeout interval duration</a>
</li>
<li><a href="#idx862" class="indexlink">Unicode Services</a>
</li>
<li><a href="#idx249" class="indexlink">unsupported devices, removing</a>
</li>
<li><a href="#idx768" class="indexlink">Upgrade Java for IPP Server</a>
</li>
<li><a href="#idx782" class="indexlink">Upgrade XML for Infoprint Central</a>
</li>
<li>URL
<ul class="indexlist">
<li><a href="#idx503" class="indexlink">for ABENDDC2-16 in CSFKSTDC</a>
</li>
<li><a href="#idx260" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="#idx257" class="indexlink">for CFSizer tool</a>
</li>
<li>for Enhanced PSP Tool
<a href="#idx186" class="indexlink">(1)</a>, <a href="#idx208" class="indexlink">(2)</a>, <a href="#idx230" class="indexlink">(3)</a>
</li>
<li>for flashes
<a href="#idx119" class="indexlink">(1)</a>, <a href="#idx124" class="indexlink">(2)</a>
</li>
<li><a href="#idx110" class="indexlink">for ISVs</a>
</li>
<li><a href="#idx61" class="indexlink">for PSP buckets</a>
</li>
<li><a href="#idx76" class="indexlink">for redbooks</a>
</li>
<li><a href="#idx233" class="indexlink">for Resource Link</a>
</li>
<li><a href="#idx70" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li>user exits
<ul class="indexlist">
<li><a href="#idx623" class="indexlink">ADRUIXIT</a>
</li>
<li><a href="#idx692" class="indexlink">ARCBDEXT</a>
</li>
<li><a href="#idx626" class="indexlink">EIOP03</a>
</li>
<li><a href="#idx628" class="indexlink">EIOP06</a>
</li>
<li><a href="#idx419" class="indexlink">FTCHKPWD</a>
</li>
<li><a href="#idx781" class="indexlink">IEFUSI</a>
</li>
<li>IEFXVNSL
<ul class="indexlist">
<li><a href="#idx607" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx351" class="indexlink">IFASMFDL</a>
</li>
<li><a href="#idx353" class="indexlink">IFASMFDP</a>
</li>
<li>IFG0193C
<ul class="indexlist">
<li><a href="#idx611" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0193G
<ul class="indexlist">
<li><a href="#idx621" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0199I
<ul class="indexlist">
<li><a href="#idx619" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019FS
<ul class="indexlist">
<li><a href="#idx589" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019FV
<ul class="indexlist">
<li><a href="#idx587" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019LA
<ul class="indexlist">
<li><a href="#idx583" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG019VM
<ul class="indexlist">
<li><a href="#idx585" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0553C
<ul class="indexlist">
<li><a href="#idx613" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG055FE
<ul class="indexlist">
<li><a href="#idx591" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IFG0EX0B
<ul class="indexlist">
<li><a href="#idx615" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>IGGPOST0
<ul class="indexlist">
<li><a href="#idx581" class="indexlink">modify for new DCBE macro option</a>
</li>
<li><a href="#idx546" class="indexlink">modify to support 31-bit UCB</a>
</li>
<li><a href="#idx573" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGGPRE00
<ul class="indexlist">
<li><a href="#idx579" class="indexlink">modify for new DCBE macro option</a>
</li>
<li><a href="#idx544" class="indexlink">modify to support 31-bit UCB</a>
</li>
<li><a href="#idx571" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGXMSGEX
<ul class="indexlist">
<li><a href="#idx617" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx777" class="indexlink">Infoprint Server</a>
</li>
<li><a href="#idx108" class="indexlink">migrating</a>
</li>
<li>NSLCTRLO
<ul class="indexlist">
<li><a href="#idx605" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLEHDRI
<ul class="indexlist">
<li><a href="#idx595" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLEHDRO
<ul class="indexlist">
<li><a href="#idx599" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLETRLI
<ul class="indexlist">
<li><a href="#idx601" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLETRLO
<ul class="indexlist">
<li><a href="#idx603" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLOHDRI
<ul class="indexlist">
<li><a href="#idx593" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLOHDRO
<ul class="indexlist">
<li><a href="#idx597" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li>NSLREPOS
<ul class="indexlist">
<li><a href="#idx609" class="indexlink">modify for new DCBE macro option</a>
</li>
</ul>
</li>
<li><a href="#idx899" class="indexlink">SDSF</a>
</li>
</ul>
</li>
<li><a href="#idx403" class="indexlink">User ID for the resolver, define</a>
</li>
<li>user modifications
<ul class="indexlist">
<li><a href="#idx103" class="indexlink">examining</a>
</li>
<li><a href="#idx847" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
<li>usermods
<ul class="indexlist">
<li><a href="#idx105" class="indexlink">examining</a>
</li>
<li><a href="#idx849" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_56" href="#IDX0_56">V</a></strong>
<ul class="indexlist">
<li><a href="#idx458" class="indexlink">VIPARANGE definitions, review</a>
</li>
<li><a href="#idx424" class="indexlink">VIPARANGE processing, understand</a>
</li>
<li>virtual storage
<ul class="indexlist">
<li><a href="#idx122" class="indexlink">backing</a>
</li>
<li><a href="#idx116" class="indexlink">verifying limits</a>
</li>
</ul>
</li>
<li><a href="#idx551" class="indexlink">VSAM IMBED, REPLICATE, and KEYRANGE support removed</a>
</li>
<li><a href="#idx472" class="indexlink">VTAM internal trace</a>
</li>
<li><a href="#idx474" class="indexlink">VTAM start list</a>
</li>
<li><a href="#idx450" class="indexlink">VTAMSG2</a>
</li>
</ul>
<strong><a name="IDX1_57" href="#IDX0_57">W</a></strong>
<ul class="indexlist">
<li>WARNUND
<ul class="indexlist">
<li><a href="#idx292" class="indexlink">IEASYSxx</a>
</li>
</ul>
</li>
<li>web address
<ul class="indexlist">
<li><a href="#idx505" class="indexlink">for ABENDDC2-16 in CSFKSTDC</a>
</li>
<li><a href="#idx262" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="#idx259" class="indexlink">for CFSizer tool</a>
</li>
<li>for Enhanced PSP Tool
<a href="#idx188" class="indexlink">(1)</a>, <a href="#idx210" class="indexlink">(2)</a>, <a href="#idx232" class="indexlink">(3)</a>
</li>
<li>for flashes
<a href="#idx121" class="indexlink">(1)</a>, <a href="#idx126" class="indexlink">(2)</a>
</li>
<li><a href="#idx112" class="indexlink">for ISVs</a>
</li>
<li><a href="#idx63" class="indexlink">for PSP buckets</a>
</li>
<li><a href="#idx78" class="indexlink">for redbooks</a>
</li>
<li><a href="#idx235" class="indexlink">for Resource Link</a>
</li>
<li><a href="#idx72" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li><a href="#idx907" class="indexlink">WebSphere MQ with SDSF</a>
</li>
<li><a href="#idx85" class="indexlink">Windows clients, support for</a>
</li>
<li><a href="#idx915" class="indexlink">WLM-managed initiators on the SDSF INIT panel</a>
</li>
<li><a href="#idx405" class="indexlink">workload queueing function for EE traffic</a>
</li>
</ul>
<strong><a name="IDX1_58" href="#IDX0_58">X</a></strong>
<ul class="indexlist">
<li><a href="#idx83" class="indexlink">XCF groups</a>
</li>
<li>XCF/XES
<ul class="indexlist">
<li><a href="#idx327" class="indexlink">messages</a>
</li>
</ul>
</li>
<li>XL C/C++ migration actions
<ul class="indexlist">
<li><a href="#idx999" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx995" class="indexlink">before installing</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_5A" href="#IDX0_5A">Z</a></strong>
<ul class="indexlist">
<li><a href="#idx49" class="indexlink">z/OS IBM TDS, no migration actions for</a>
</li>
<li><a href="#idx20" class="indexlink">z/OS Management Facility, IBM</a>
</li>
<li><a href="#idx80" class="indexlink">z/OS root size</a>
</li>
<li><a href="#idx50" class="indexlink">z/OS Security Level 3, no migration actions for</a>
</li>
<li><a href="#idx445" class="indexlink">z/OS UNIX file destinations</a>
</li>
<li>z/OS UNIX migration actions
<ul class="indexlist">
<li><a href="#idx1031" class="indexlink">after first IPL</a>
</li>
<li><a href="#idx1023" class="indexlink">before first IPL</a>
</li>
<li><a href="#idx1007" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>z/OS UNIX System Services Connection Scaling
<ul class="indexlist">
<li><a href="#idx1019" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li><a href="#idx21" class="indexlink">z/OSMF</a>
</li>
<li>z10 server
<ul class="indexlist">
<li><a href="#idx185" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx175" class="indexlink">compatibility changes</a>
</li>
<li><a href="#idx176" class="indexlink">migrating to</a>
</li>
<li><a href="#idx177" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>z11 mode
<ul class="indexlist">
<li><a href="#idx813" class="indexlink">JES2</a>
</li>
</ul>
</li>
<li>z114 server
<ul class="indexlist">
<li>compatibility changes
<a href="#idx150" class="indexlink">(1)</a>, <a href="#idx166" class="indexlink">(2)</a>
</li>
<li>migrating to
<a href="#idx151" class="indexlink">(1)</a>, <a href="#idx153" class="indexlink">(2)</a>, <a href="#idx167" class="indexlink">(3)</a>, <a href="#idx169" class="indexlink">(4)</a>
</li>
</ul>
</li>
<li>z196 server
<ul class="indexlist">
<li>compatibility changes
<a href="#idx144" class="indexlink">(1)</a>, <a href="#idx160" class="indexlink">(2)</a>
</li>
<li>migrating to
<a href="#idx146" class="indexlink">(1)</a>, <a href="#idx148" class="indexlink">(2)</a>, <a href="#idx162" class="indexlink">(3)</a>, <a href="#idx164" class="indexlink">(4)</a>
</li>
</ul>
</li>
<li>z890 server
<ul class="indexlist">
<li><a href="#idx240" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx215" class="indexlink">compatibility changes</a>
</li>
<li><a href="#idx218" class="indexlink">migrating to</a>
</li>
<li><a href="#idx222" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>z9 server
<ul class="indexlist">
<li><a href="#idx207" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx197" class="indexlink">compatibility changes</a>
</li>
<li><a href="#idx198" class="indexlink">migrating to</a>
</li>
<li><a href="#idx199" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>z990 server
<ul class="indexlist">
<li><a href="#idx236" class="indexlink">coexistence requirements</a>
</li>
<li><a href="#idx211" class="indexlink">compatibility changes</a>
</li>
<li><a href="#idx214" class="indexlink">migrating to</a>
</li>
<li><a href="#idx220" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>zEC12 server
<ul class="indexlist">
<li><a href="#idx139" class="indexlink">compatibility changes</a>
</li>
<li>migrating to
<a href="#idx140" class="indexlink">(1)</a>, <a href="#idx142" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>zEnterprise
<ul class="indexlist">
<li>migrating to
<a href="#idx145" class="indexlink">(1)</a>, <a href="#idx161" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="#idx743" class="indexlink">zFS</a>
</li>
<li><a href="#idx1021" class="indexlink">zFS, migrating from HFS to</a>
</li>
<li><a href="#idx740" class="indexlink">zFS cloning support</a>
</li>
<li><a href="#idx742" class="indexlink">zFS compatibility mode aggregates</a>
</li>
<li><a href="#idx707" class="indexlink">zFS file system, DFSMSdfp</a>
</li>
<li><a href="#idx741" class="indexlink">zFS multi-file system aggregates</a>
</li>
<li><a href="#idx736" class="indexlink">zFS storage requirements</a>
</li>
<li><a href="#idx746" class="indexlink">zFS virtual storage verification</a>
</li>
<li><a href="#idx738" class="indexlink">zfsspace utility</a>
</li>
<li><a href="#idx66" class="indexlink">zSoftCap</a>
</li>
<li><a href="#idx65" class="indexlink">zSoftware Migfration Capacity Planning Aid (zSoftCap)</a>
</li>
</ul>
<a id="Bot_Of_Page"></a>
</body>
</html>
